You can merge changes made on a branch into your working
copy by giving the -j branchname
flag to the update subcommand. With one -j
branchname
option it merges the changes
made between the point where the branch was last merged and newest
revision on that branch (into your working copy).
If you wish to revert to the older CVS behaviour of merging from the point the branch forked, specify the -b option.
If you are updating from an Unix CVS server of older cvsnt server that doesn't support merge points, then the merge will always be done from the branch point.
+-----+ +-----+ +-----+ +-----+ ! 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. the section called “Conflicts example”.
If your source files contain keywords (Chapter 13, Keyword substitution), you might be getting more conflicts than strictly necessary. See the section called “Merging and keywords”, for information on how to avoid this.
The checkout command also supports the
-j branchname
flag. The same
effect as above could be achieved with this:
$ cvs checkout -j R1fix mod $ cvs commit -m "Included R1fix"
It should be noted that update -j
tagname
will also work but may not produce
the desired result. the section called “Merging can add or remove files”, for
more.