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@9 commit patch P onto trunk, making trunk@10 branch trunk@9 to B, making B@11 merge trunk to B, making B@12 then: diff(trunk@10, B@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@r1 to branch2@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
