monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Monotone-devel] Re: branches


From: graydon hoare
Subject: [Monotone-devel] Re: branches
Date: Mon, 03 May 2004 23:50:03 -0400
User-agent: Mozilla Thunderbird 0.5 (X11/20040208)

Derek Scherger wrote:
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?

it depends if the files have the same content. if they do, I'd think it ought to be mergable, as it's an identical action. if they're different files, I think it's considered a conflict.

I suppose we really ought to split that case out into a 2-way merge. the tree-level merging algorithm is sort of ad-hoc, and a bit conservative, so I'm certainly willing to try tidying these sort of cases up. in general we also need a "ask user to resolve tree layout conflict" hook. I was thinking something along the lines of writing out a work file (a la MT/work) for each edge, and reading back a user-merged version.

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?

yup. maybe in the future I'll add a "monotone branch" command which commits a "monotone bump"'ed version to the new branch, just to make users comfortable. but it'd be purely for decoration.

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

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.

-graydon




reply via email to

[Prev in Thread] Current Thread [Next in Thread]