Go to the previous, next section.
You can include the changes made between any two revisions into your working copy, by merging. You can then commit that revision, and thus effectively copy the changes onto another 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". In previous versions of CVS there was a special command, `cvs join', that was used to merge changes between branches.
Consider this revision tree:
+-----+ +-----+ +-----+ +-----+ +-----+
! 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 !
+---------+ +---------+ +---------+
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.5
$ 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.3, into your working copy
# of the file.
$ cvs commit -m "Included R1fix" # Create revision 1.6.
A conflict can result from a merge operation. If that happens, you should resolve it before committing the new revision. See section 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"
With two `-j revision' flags, the update
(and checkout) command can merge the differences
between any two revisions into your working file.
$ cvs update -j 1.5 -j 1.3 backend.c
will remove all changes made between revision 1.3 and 1.5. Note the order of the revisions!
If you try to use this option with the checkout
command, remember that the numeric revisions will
probably be very different between the various files
that make up a module. You almost always use symbolic
tags rather than revision numbers with the
checkout command.
Go to the previous, next section.