Re: [Monotone-devel] Re: branches

[Christof Petig]

graydon hoare schrieb:
> > I had another idea for a more familiar 3 way merge hook too... use the 
> > rcs marking merge to create a file with marked conflicts then land 
> > that in an editor for further fixing. I assume that I can do these two 
> > things in the hook without any problems? It's either that or read the 
> > xxdiff manual and figure out how to work it properly! ;)
>
>
> yes, erhmm.. didn't you already send a patch which implements this in 
> the 3-way merge hook? I think we rejected (really postponed) it on the 
> grounds that it would commit the marked files directly to the database, 
> and that was undesirable. I'm not opposed to the idea in general, I just 
> think it needs to accompany a bit of adjustment with the behavior of 
> merge (say merging into the working copy and not immediately committing).
>
> as an aside, I *would* recommend playing with xxdiff (or sdiff, meld, 
> ediff, kdiff3, etc.) as they are really quite lovely tools for rapidly 
> walking through a complex merge. I can't force you to, but I've 
> personally found this to be an indispensible category of tool. I almost 
> never merge work with rcsmerge markers anymore, unless I'm using CVS; I 
> find the visual 3-way views much easier.

I liked xxdiff's display too. Though it took me some time to realize to 
use the "refresh/recycle" like button to resolve changelog conflicts.

Though I would love to see a cooperative merging possible within 
monotone. Like "merge two heads, mark conflicts somewhere and commit the 
conflicts 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."

One way might be to use RCS marking and a special flag (somewhere inside 
MT/) indicating that this file still needs merging.

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 whats 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).

> > I've been wondering a bit whether the repeated pairwise merges might 
> > be more controllable if it only did one pair and quit. Then the merge 
> > process might be more like heads... merge... heads... merge...  so 
> > that I can see what I'm getting and quit when I'm tired rather than 
> > having an endless (ok long) cycle of xxdiff's popping up at me. 

IIRC that's on the todo list.

> > Personally I think I'd prefer that, but until I've done it a few times 
> > both ways I'm just speculating. What about a hook to control this 
> > (merge one pair verses merge all pairs)?
>
>
> yes, this is also possible. it might work well with, as you suggest, the 
> merging-into-working-copy idea. I think it's been brought up on this 
> list several times in the past, and I'm not opposed to it. I'd just like 
> to see concrete issues worked out, and a minimally-intrusive bit of code 
> developed, and I haven't gotten around to doing so.

My proposal:
   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). Of course you are free to use xxdiff, rcs_merge or any 
other way to merge the files and commit midway.

   Christof