Symmetry for branching, move tracking and merging

I want to share, briefly, one of the key concepts that is guiding my thinking about move tracking. It's nothing amazing, in fact it may seem so obvious that it hardly needs mentioning. What's more surprising is that we haven't paid more attention to this idea before.

In order to build a sane merging system, we expect certain symmetries in the data model.

Example:

  * start with trunk_at_9
    commit patch P onto trunk, making trunk_at_10
    branch trunk_at_9 to B, making B_at_11
    merge trunk to B, making B_at_12
    then: diff(trunk_at_10, B_at_12) should be nil

Bleedin' obvious, heh?

The idea is that these two things should be symmetrical, interchangeable:

  * a change along a branch

  * a difference between two related branches

That generalizes to:

  * uniformity of the difference from branch1_at_r1 to branch2_at_r2
    for any values of: branch1, r1, branch2, r2
    where branch1 and branch2 are 'related' (formally: in the same branch family)

  * diffs obey some (more or less obvious) arithmetic rules such as:
    diff(A,B) (+) diff(B,C) == diff(A,C)
    diff(A,B) (+) diff(B,A) == nil
    and so on

Not just roughly but precisely, testably so.

A "difference" API should be able to fetch any such difference.
An "edit" or "patch" or "merge" API should be able to apply any such difference.

We're talking about the versioned content of the branches, of course, and not the revision metadata (log messages, etc.).

I think this is a simple yet powerful idea. By deliberately testing for compliance, we could quickly discover design problems as well as implementation bugs in either our current code base or a future design. Of course I'll be wanting to test my move tracking model against this concept.

Where this gets really interesting is in the definition of a 'move'. It's easy to come up with models for move tracking that fail to meet this criterion. The model I am working on at the moment does, I believe, meet this criterion, and I believe that's really important.

- Julian
Received on 2015-03-06 12:13:54 CET