[Monotone-devel] cooperative/parallel/resumed merging (was Re: branches)

[Christof Petig]

Hi,

I did not get a single response to my proposal so I dare to repeat it 
here. Rationale is to make merging a process which can directed to 
multiple people and/or stopped and resumed.

Since this is such an interesting feature I was astonished I got no 
feedback. I'm not sold to this particular implementation but I sincerely 
want a solution.

---- original proposal (somewhat edited for clarity) -------

I would love to see a cooperative merging possible within
monotone. Like "merge two heads, mark conflicts somewhere and commit the
conflict markers as a new manifest. Then multiple people might be able 
to resolve the conflicts (distributed in time and space=files) until all
are done and the version gets official."

[rcs markers proposal deleted, I don't like that one any more]

Another way might be a special purpose file that contains the three file
IDs to merge (3 way) and a monotone command to resolve that conflict in
one file in the working copy. This way we would not need to mark the
file as unresolved: it would not compile and anybody looking into it
will clearly know what it is about.

E.g.
#### Unresolved monotone merge between ####
ff4a98592a893c5783221445a196955a4974f1d4
7d157d7c000ae27db146575c08ce30df893d3a64
31836aeaab22dc49555a97edb4c753881432e01d
#### use monotone resolve foo.cc to resolve it ####

But this will clearly get a nightmare once somebody merges a conflict
file with another conflicting head (should fail early).

Proposal: Merging with any head which affects a conflict marker file 
without completely replacing it must fail. If two people merge a file we 
have two heads which should merge cleanly (any 3 way merge (should be 
avoided) must take the first ID in the file as the base (IIRC) and not 
the ID of the marker).

My proposal for the merge into working copy command:
   monotone merge 4e1243bd22c66e76c2ba9eddc1f91394e57f9f83
merges current working directory (must be unchanged and must contain no
conflict marks) with 4e12, telling which files successfully merged and
which files had conflicts. You can then discard the merge by monotone
revert or commit the new head (should get specially certified as
unresolved and thus not for public use). Of course you are free to use 
xxdiff, rcs_merge or any other way to merge the files and commit midway.

I can't see any problems with this approach (other than that the 
representation of an unmerged file in the manifest and the contents of 
the unmerged file need further thinking).
   Christof

PS: monotone resolve should loop over all conflicting files (similar to 
the current UI). So the current behaviour would be like "monotone co 
<first head> ; for i in <remaining heads> ; do monotone merge $i ; 
monotone resolve ; [monotone commit] ; done". But would be easily 
restartable :-)