Now let's try something a bit more interesting: experimenting with
conflicts.

In one replica, add "FOO" after "one" (on the same line) and "BAR" after
"two".  In the other replica, add "BAZ" after "two" and "GLOP" after
"three".  Synchronize and notice what happens, both in the states of the
replicas after synchronization and in the summary printed by Harmony of what
it has done.

(Yes, we know we need to working on making Harmony's output easier to
understand!)

At this point, the first and third lines are known to be synchronized and
can be further edited; changes made just in one replica will be propagated
to the other.  The second line, on the other hand, is in conflict and will
stay so until the conflict is repaired.  There are two ways to do this:

   - edit both copies of the second line so that they are identical and
     re-synchronize (the new version will be accepted as the new
     synchronized value for this line)

or

   - edit one copy back to its original state (just "two") and
     resynchronize (the changed version from the other replica will now be
     propagaged) 

Try both ways.

(Note that the second behavior is a slight difference between the
implementation and the algorithm described in our DBPL paper.  The current
implementation does not record conflicts explicitly in the archive.)

You can also edit header lines, of course, and the same rules of conflicts
apply there as well.  Try this.

Go on to demo6 when you are ready.

* HEADER
one
two
three