5.7 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
|