> urticator.net

  About This Site
> Domains

> Computers

> Concepts for Persistent Objects
  Language Design Principles

  Instances and Copies
  Branches and Growth Points
> Synchronization and Merging
  An Example

  Relation to Commutative Diagrams

Synchronization and Merging


To get in the right frame of mind for thinking about synchronization and merging, you might want to go read about commutative diagrams first. I'll discuss the relation between the two in more detail later, in a subessay.

Now let's get back to thinking about objects. Suppose two people are working on branched versions of a single object.

It's easy to imagine that the two might like to sync up—if, say, the object is a large block of open-source code, and the two have fixed independent bugs. So, the left-hand person applies the changes made on the right, the right applies the changes made on the left, and voila.

That's bidirectional synchronization, a composite operation built from two unidirectional synchronizations. On the other hand, it's also easy to imagine that the two might be working together more closely, and might want the object concept to include the fact that they've agreed to produce a single, definitive version.

That's merging, an atomic operation.

Actually, I think there's more to merging than that—there are some subtleties about growth points that I glossed over. Since merging is an operation that's not part of normal growth, the person (or, rather, role) that does the merging doesn't own any of the existing growth points, almost by definition. Here's what I imagine really happens.

  • The branches to be merged finish growing and lose their growth points. (Or, if they don't finish growing, the growth points remain where they are, unaffected by the merge process.)
  • The merge role creates new growth points on the branches.
  • The role merges the branches into a single version with a single growth point.
  • With the task completed, the single growth point is removed.
  • Other growth points are created on the new version as needed.

You may sometimes hear the word “merge” used to refer to some form of synchronization, but that's clearly bad terminology, because merging is all about two (or more) things becoming one, not about two things becoming more similar. How can you remember which is which? I offer the following helpful aphorism, adapted from The Tao Is Silent.

The merge that can be merged is not the true merge.

Even the word “synchronization” isn't absolutely perfect, because it suggests synchronizing watches, which doesn't make much sense as a bidirectional operation. (Of course, “synchronization” certainly should suggest watches, since, according to my dictionary, its Greek roots mean “same time”.)



  See Also

@ September (2000)