[Monotone-devel] Re: branches

[Derek Scherger]

graydon hoare wrote:

> it doesn't exactly fail; it simply asks the user to intervene and 
> resolve the conflict. a special case of this is when there are 
> conflicting tree-layout changes (rather than intra-file changes); 
> currently we don't have an "ask user for help" hook for that. we should. 
> that's a missing feature.

I think I'm managing to hit that special case too often. ;)

I seem to end up adding a file on both branches occasionally, rather than adding it first 
on the "source" branch and propagating that to the "target" branch and then making 
differing changes.

Does it sound right that if I add a file under the same name on both branches 
independently that this will be considered a tree layout conflict?

BTW, What's the proper way to create a branch? I'm checking out an existing branch foo and 
then just doing monotone commit --branch=bar 'foobar'. Is this the right thing to do?

> if you'll forgive my guessing, I think you might have confused "parallel 
> edits" and "conflicting edits". suppose, in your example, you have some 

Nope, it was the tree conflict that was causing me grief. I think I have that 
worked out now.

>   --- common ---\------ common edit ----- common foo.c
>                  \
>                   \---- platform edit ---- platform foo.c
>
> you can propagate from common to platform. this will do a 3-way merge 
> between the common and platform foo.c files, using the branchpoint as 
> ancestor, and place the result in the platform file. you could use this 

Great, you have at least confirmed that I should be able to do what I'm trying 
to do...

> for example to move bugfixes around. it is *very likely* that the 
> changes will be mergable. most changes are. that's the fundamental 
> insight CVS made: most changes do not conflict, even within the same file.

I've recently been using VSS (under much duress) at work and man, locked edits are brutal. 
I vaguely remember the switch to unlocked merging work with cvs being a bit strange for a 
couple of days but switching back is much harder, and less permanent I hope.

> when there is a conflict -- meaning both changes affect the same lines 
> in the same file in an incompatible way -- only then does the user need 
> to intervene. but the intervention is usually quite easy. install xxdiff 
> or ediff, and it is simply a matter of clicking on a couple hunks and 
> possibly editing a couple of lines.

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! ;)

> consider that "monotone propagate" moves one set of changes between one 
> source and one destination branch. you could organize your work so that 
> each user -- or even each change! -- goes in a separate branch, and 
> users who want to integrate or exchange work need to explicitly ask for 
> a propagate from "someone else's branch" to "their own branch". that is 
> a bit like how arch works. you have to run "propagate" quite often, but 
> it's very flexible: you're saying "give me exactly these changes, and no 
> others".
>
> in comparison, consider that "monotone merge" collects "all" the 
> parallel changes made to a given branch and tries to merge them into a 

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

> single head. this could be dozens of changes made by many independent 
> people, for different reasons. merge is a powerful command. it's also a 
> blunt and inflexible command. you aren't picking and choosing amongst 
> incoming changes, you're saying "please try to form a consensus head". 
> that is a bit more like how CVS works (with the communication order 
> inverted: commit before merge rather than merge before commit).
>
> does this clarify matters?

Certainly clarifies the differences between merge and propagate and I think it should help 
me get going.

I'm going to work with this for a while and see where I get. It does seem to do what I 
want, as long as I'm careful not to get into the conflicting tree layout state. It does 
seem easy enought to get out of this conflicted state too... drop the offending file from 
the target branch, propagate and it's there. Although any changes on the bar branch get 
clobbered... and I'm working on a patch to try and deal with that.

Thanks again!

Cheers,
Derek