[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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
††† 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

This is an archived mail posted to the Subversion Dev mailing list.