Brian Collins wrote:
> Eric Siegerman wrote:
[...]
>> The Right Thing(TM) would probably be to collapse (ie. "merge and
>> forget") the branch and start a new one, rather than doing
>> multiple merges from the existing one -- but I'm not quite sure
>> how to do this in a context of ongoing bug-fixes to the previous
>> release.
> I don't think the Right Thing's practical in this situation.
> Our plan is to create a patches branch for each release
> and tag "service packs" at various points along the branch.
> Programmers fixing bugs on the branch will be required to
> merge them back to the trunk as they go so that we don't
> end up with an enormous merge job when we cut a new
> release. In 99% of cases (he said hopefully! ;-) this should
> be a simple merge process because the change on the
> trunk will be the same as on the branch. Of course,
> if there's a better way to do it, I'm open to suggestions ...
The Right Thing is probably more along the lines of
merging only the part of the branch that hasn't already been
merged each time, and don't re-merge the entire branch
each time.
Do this with tags, something like this,
Suppose your branch is called "Branch", and suppose
the point at which it forks off from the trunk is tagged
(with a non-branch tag) "trunk_Branch_fork"
The first merge would go like this:
cvs tag -r Branch Branch_merge_1 everything
cvs co everything
cd everything
cvs update -d -P -j trunk_Branch_fork -j Branch_merge_1
(resolve conflicts)
cvs commit -m 'merged between tags trunk_Branch_fork and Branch_merge_1 to
the trunk"
The 2nd merge would go like this:
cvs tag -r Branch Branch_merge_2 everything
cvs co everything
cd everything
cvs update -d -P -j Branch_merge_1 -j Branch_merge_2
(resolve conflicts)
cvs commit -m 'merged between tags Branch_merge_1 and Branch_merge_2 to the
trunk"
And so on.
That way, you'd avoid ever merging in the same stuff twice.
Some people prefer to use a moving tag to mark the last thing that
was merged in on the branch rather than a new tag each time.
There is one caveat. When you use "cvs update" with two "-j" options,
files which are removed between these two tags are removed in the
branch (or trunk) you are merging into without possibility of conflict
as I remember. This is because CVS does not assume that the first -j
represents the common ancestor of the branch your are merging into,
(as it might well not be an ancestor, e.g. if you are doing a reverse
merge. That is with two -j options, the concept of a common ancestor
doesn't make sense. (So, you might want to do the first merge with
just one -j option for that reason.) Conflict detection with two -j options
may be a little different too, more along the lines of how "patch" rejects
hunks since CVS can't know about a common ancestor. (maybe someone
more knowledgeable would care to elaborate on that a little?)
Hope it helps.
-- steve
