Symmetry for branching, move tracking and merging
From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Fri, 6 Mar 2015 11:13:04 +0000
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.
† * start with trunk_at_9
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
† * diffs obey some (more or less obvious) arithmetic rules such as:
Not just roughly but precisely, testably so.
A "difference" API should be able to fetch 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.
This is an archived mail posted to the Subversion Dev mailing list.