[Monotone-devel] Re: branching policy

[Bram Cohen]

Nathaniel Smith wrote:

> I'd be
> very interested in hearing more about your exact use case,
Branches are centralized and persistent and form a spanning tree. New 
branches can be created by specifying the current branch to be their 
initial neigbor. Editing of branches is generally done as normal. 
There's a special 'pull' command to pull data from a neigbor into a 
specific branch. There's also a reneigbor command to sever the 
connection to a specific neigbor and make a new one to a specified 
branch, which passes if (1) the reneigboring won't form a loop, and (2) 
the current state of the new neigbor has the lca with the old neigbor as 
an ancestor. Both pulling and reneigboring outright fail and force you 
to revert if someone else does a pull or reneigbor of the same 
connection before you're done.

The advantages of this approach are (1) It follows intuitively and 
safely - changes always start at one place and propogate out, and there 
isn't much opportunity to shoot yourself in the foot by pulling 
something which really shouldn't be pulled (but it's still far from 
totally impossible, of course). It also avoids all merge weirdness (and 
specifically keeps things to what the svn merge command can handle) by 
only allowing merges which only have a single LCA. This property is nice 
regardless of whether you want implicit undo or implicit cherry-pick, by 
the way. For either feature the cases where there could be potential 
difficulties are avoided. My scripts will just support implicit undo, 
for overwhelming reasons of expediency.

This all can be accomplished with just a little bit of scripting, some 
mild shoving of metadata into versioned files, and some completely 
roasonable usage of svn's switch command. I will of course be making the 
scripts public once they're reasonably operational.

> and curious
> if you've considered using monotone instead of SVN for the backend?
>  
I'm using svn because I want it up and running in days rather than weeks 
or months. The result will likely be much like CVS was in the early days 
- objectively awful, and darn near a literal weekend hack, but 
completely utilitarian and in many cases a better approach than the 
alternatives.

> <bram> (by the way, if njs could say whether the LCA is 'the node which is an
>  ancestor of both nodes being merged which has no descendants which are
>  ancestors of both nodes being merged' I'd much appreciate it) 
>  
[snip answer saying 'yes, but there isn't always just one node with that 
property']

Thank you. This really should be documented somewhere so people don't 
have to keep reinventing the concept.

By the way, I think LCAs really are very fundamental to safe merging. 
Basically, if a tree merge is criss-cross you can try to make each 
individual file okay by finding an LCA for each file, and if there's a 
file which has a criss-cross merge you can try to find an LCA for each 
line, and if there's a line which has no single LCA then you've reached 
such a hosed situation that simply displaying the alternate versions and 
asking the user to decide which should win might not fully capture the 
full information which should be escalated to the user.

And yes, I know I still need to write up the subtleties of resolution, 
the meaning of circular staircase, expand on the whacked weirdness which 
can happen with criss-cross undo, and write up my 3-way merge theory. 
Maybe once I'm done with all that I'll rewrite the darcs back end to be 
based on a convergent merger. All in my *copious* free time, of course.

-Bram