Danny Angus wrote:
For binary files and most of the changes we're making now, we don't really need to merge. As long as we can continue to do this, the better. If we really get into this, I would suggest we push for a release of HEAD as 2.2 or an early non-contentious 3.x release and branch again for another stabilization.I think change the HEAD and merge into the branch. or add to HEAD and then branch the new file with the same branch name. But thats just an informed guess, someone else may have a firmer grasp..d.
But if you need to merge, here are two excerpts from a CVS guide:
--------------------------------------------------------------------------
Merging an entire branch
You can merge changes made on a branch into your working copy by giving the -j branch flag to the update command. With one -j branch option it merges the changes made between the point where the branch forked and newest revision on that branch (into your working copy).
The -j stands for "join".
Consider this revision tree:
+-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+
!
!
! +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
The branch 1.2.2 has been given the tag (symbolic name) R1fix. The following example assumes that the module mod contains only one file, m.c.
$ cvs checkout mod # Retrieve the latest revision, 1.4
$ cvs update -j R1fix m.c # Merge all changes made on the branch,
# i.e. the changes between revision 1.2
# and 1.2.2.2, into your working copy
# of the file.
$ cvs commit -m "Included R1fix" # Create revision 1.5.
A conflict can result from a merge operation. If that happens, you should resolve it before committing the new revision. See Conflicts example.
The checkout command also supports the -j branch flag. The same effect as above could be achieved with this:
$ cvs checkout -j R1fix mod
$ cvs commit -m "Included R1fix"
--------------------------------------------------------------------------
Merging from a branch several times
Continuing our example, the revision tree now looks like this:
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !
+---------+ +---------+
where the starred line represents the merge from the R1fix branch to the main trunk, as just discussed.
Now suppose that development continues on the R1fix branch:
+-----+ +-----+ +-----+ +-----+ +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !----! 1.5 ! <- The main trunk
+-----+ +-----+ +-----+ +-----+ +-----+
! *
! *
! +---------+ +---------+ +---------+
Branch R1fix -> +---! 1.2.2.1 !----! 1.2.2.2 !----! 1.2.2.3 !
+---------+ +---------+ +---------+
and then you want to merge those new changes onto the main trunk. If you just use the cvs update -j R1fix m.c command again, CVS will attempt to merge again the changes which you have already merged, which can have undesirable side effects.
So instead you need to specify that you only want to merge the changes on the branch which have not yet been merged into the trunk. To do that you specify two -j options, and CVS merges the changes from the first revision to the second revision. For example, in this case the simplest way would be
cvs update -j 1.2.2.2 -j R1fix m.c # Merge changes from 1.2.2.2 to the
# head of the R1fix branch
The problem with this is that you need to specify the 1.2.2.2 revision manually. A slightly better approach might be to use the date the last merge was done:
cvs update -j R1fix:yesterday -j R1fix m.c
Better yet, tag the R1fix branch after every merge into the trunk, and then use that tag for subsequent merges:
cvs update -j merged_from_R1fix_to_trunk -j R1fix m.c
--
Serge Knystautas
Loki Technologies
http://www.lokitech.com
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
