[Top][All Lists]

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

RE: Maintaining branches...

From: Stephen Cameron
Subject: RE: Maintaining branches...
Date: Tue, 12 Jun 2001 13:09:01 -0700 (PDT)

Ralph Mack (address@hidden) wrote:

> What I'm reading about branching and merging makes me think that
> a branch-merge pair on CVS is a one-way trip, that once you have
> merged from a branch you can't merge to that branch from the
> updated mainline and then merge back again. Another interpretation
> is that you have to specify your merge "control points" (from, to,
> last common ancestor) manually.
For the first merge, CVS can figure the common ancestor (given only one -j
option.)  For subsequent merges, you don't want it to figure the common
ancestor because if you allow it to, it will re-merge in the changes you
already merged, potetially causing lots of conflicts that you've already
resolved the first time.

The typical sequence is something like:

1st merge:

cvs tag before_merge_1
cvs tag -r from_branch merge_point_1
cvs update -dP -j merge_point_1
(resolve conflicts)
cvs commit -m 'merged up to merge_point_1 from_branch"

2nd merge:

cvs tag before_merge_2
cvs tag from_branch merge_point_2
cvs update -dP -j merge_point_1 -j merge_point_2
(resolve conflicts)
cvs commit -m 'merged up to merge_point_2 from_branch"

> Does CVS branching and merging allow the developer to do the kind
> of rev-up/promote merge pattern that we do routinely with ClearCase?
> If you have to specify all three control points, shouldn't CVS be
> able to figure out the last common ancestor from the merge history?
> Is this another situation complicated by directories not being
> versioned?

There is no merge history.  As far as CVS is concerned, changes commited which
are the result of a merge are indistiguishable from a situation where you just
typed in those same changes again and commited them.  CVS is finished with the
"merge" operation as soon as the "cvs update" command completes.  The
subsequent "commit" is not a merge as far as CVS knows.  CVS's idea of merge
is, I think, pretty similar to:

cvs diff -uN -r abc -r xyz | patch -p0

but with conflicts handled a bit differently 

With that in mind, your process seems a bit extreme, with more than the usual
amount of branching and merging going on, vs. a typical CVS shop...(not that I
know what that really is.)

Note also, there is a subtle implication that a merge using 2 -j options
differs from using just 1 -j option in that with 2 -j options, for files which
are removed between the two tags, that removal is merged in without possibility
of conflict.  This is because for such a merge, CVS can't know that there
really is a common ancestor, or what span of revisions to check for conflicting
changes.  (all it knows is two points... it is very much like running "patch") 
You could be running a reverse merge, for instance, to undo changes, in which
case a common ancestor is nonsense. 

Looking at this more (than I have before) it looks like the code calls
RCS_merge in much the same way whether one or two -j options is given, so,
assuming "cvs update -j rev1 -j ref2", it looks like it takes "rev1" to be the
"common ancestor", when in reality, it may not be a common ancestor at all.  I
think the magic is in "cvs update" finding the common ancestor (with one -j)
and filling it in for "rev1".  So, if RCS_merge is taking rev1 to be the
"common ancestor" and the basis for conflict detection, It kind of seems like
the same logic should apply for file removals too...if you truncated the file
to zero length, that and that would make a conflict, shouldn't deleting it make
a conflict too?  I'm not 100% sure about that.  (Everytime I look at this part
of the code it seems a bit weird.  Sorry to go off on a tangent.)

-- steve

Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!

reply via email to

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