[Top][All Lists]

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

Re: Best practice for making changes to "old" branches

From: Sergei Organov
Subject: Re: Best practice for making changes to "old" branches
Date: Fri, 31 Mar 2006 16:40:05 +0400
User-agent: Gnus/5.110004 (No Gnus v0.4) XEmacs/21.4.18 (linux)

"Adam Lipscombe" <address@hidden> writes:
> If we fix it in their original branch, how do we propagate the change into
> the head? 
> (The branch has already been merged in?)

CVS doesn't remember what has and what has not been merged, so you are
free to merge as many times as you wish. However, to prevent excessive
conflicts, you may wish to do it as follows:

Checkout the branch and tag it's current state if you didn't yet.

cvs get -r the_branch the_module
cd the_module
cvs tag the_branch_last_merge

then make changes on the branch, commit them, then in a directory that
contains checked-out mainline, do

cvs update -dP -j the_branch_last_merge -j the_branch
... resolve conflicts (if any), test the resulting changes, etc. ...
cvs commit

then don't forget to change back to the the_module on the_branch
directory and move the 'the_branch_last_merge' tag:

cvs update -dP
cvs tag -F the_branch_last_merge

so that next time you do another change to this branch you will have a
correct "last merge" point.

However, if I were in this situation, I'd merge to the "2 branches ago"
branch first, then from "2 branches ago" to "1 branch ago", and finally
to the mainline. I'm sure you'll figure out how to do it using the above

-- Sergei.

reply via email to

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