[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Monotone-devel] Re: branches
From: |
Derek Scherger |
Subject: |
[Monotone-devel] Re: branches |
Date: |
Mon, 03 May 2004 20:46:22 -0600 |
User-agent: |
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040225 |
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
- [Monotone-devel] branches, Derek Scherger, 2004/05/02
- [Monotone-devel] Re: branches, graydon hoare, 2004/05/03
- [Monotone-devel] Re: branches,
Derek Scherger <=
- [Monotone-devel] Re: branches, graydon hoare, 2004/05/03
- Re: [Monotone-devel] Re: branches, Christof Petig, 2004/05/04
- [Monotone-devel] cooperative/parallel/resumed merging (was Re: branches), Christof Petig, 2004/05/11
- Re: [Monotone-devel] cooperative/parallel/resumed merging (was Re: branches), Patrick Mauritz, 2004/05/11
- [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches), graydon hoare, 2004/05/13
- Re: [Monotone-devel] Re: cooperative/parallel/resumed merging (was Re: branches), Joel Rosdahl, 2004/05/13