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".
+-----+ +-----+ +-----+ +-----+
! 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 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"
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
With two
`-j
revision
'
flags, the
update
(and
checkout
) command can merge the differences
between any two revisions into your working file.
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 when operating on
multiple files, remember that the numeric revisions will
