[Top][All Lists]

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

Re: Merging in CVS

From: Kaz Kylheku
Subject: Re: Merging in CVS
Date: 4 Dec 2002 11:49:25 -0800

"Stefan Monnier <address@hidden>" 
<> wrote in message 
> > The merge tracking in Meta-CVS is done by automating a certain logical
> > procedure involving CVS tags; it's a technique which I used to perform
> > manually. Its advantage is that it does not pollute the repository
> > with too many tags, and it requires only one global tagging operation
> > per merge!
> > A merge sequence is tracked with two tags, call them ``zero'' and
> > ``one''. Both the source and target branch names are encoded into
> > these tags. The merge operations alternate between these two tags; one
> > merge will ``rtag -F'' using the zero tag. The next merge will use the
> > one tag. Then the zero tag, and so forth.
> Could you explain what the two tags are used for ?
> I don't understand who that works.  It seems to me that only the
> `commit' part of the merging procedure should make any modification
> (including adding tags).  What am I missing ?

In CVS, merges are tracked using tags which are placed into the source
branch. The tags are needed in order to identify and select the two
revisions which delimit the delta that is to be merged.

Doing this properly is important otherwise lost merges could
result---changes which were committed to a stream, but not picked up
by a merge due to a race condition or other problem. You must always
tag the tip of the source branch before merging, and then merge from
the previously tagged revision to the newly tagged revision. This way
it is not possible for someone to sneak in a change just after you
merge, but before you tag.

A few approaches are possible: for example, you can create a unique
tag each time you merge, and merge from the immediately previous
unique tag to the new one. The merge tags can be incrementally
numbered, or they can contain a time and date.

I came up with the two-tag method in order to avoid polluting the
repository with an indefinite sequence of merge tags.

Instead of inventing a new tag, the older one of the two is reused. So
one merge goes from tag-0 to tag-1, then on the next merge, tag-0 is
pushed to the tip, and the merge goes from tag-1 to tag-0. The two
tags march down the branch like a pair of feet, each stride stepping
over the next chunk to merge.

CVS allows an existing tag to be pushed to the tip of a branch in one
operation (tag -F) so with this method we don't have to invoke an
additional time-consuming untag operation to clean out an obsolete

reply via email to

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