Merging repeatedly from branch to trunk is good for the people on the trunk, because they see all of their own changes and all the changes from the branch. However, the developer on the branch never gets to incorporate any of the work being done on the trunk.
To allow that, the branch developer needs to add an extra step every now and then (meaning whenever he feels like merging in recent trunk changes and dealing with the inevitable conflicts):
paste$ cvs update -j HEAD
The special reserved tag
HEAD means the tip of the trunk. The
preceding command merges in all of the trunk changes between the root of
the current branch (
Exotic_Greetings-branch) and the current
highest revisions of each file on the trunk. Of course, qsmith should
tag again after doing this, so that the trunk developers can avoid
accidentally merging in their own changes when they're trying to get
The branch developer can likewise use the trunk's merge tags as boundaries, allowing the branch to merge exactly those trunk changes between the last merge and the trunk's current state (the same way the trunk does merges). For example, supposing jrandom had made some changes to hello.c after merging from the branch:
floss$ emacs hello.c ... floss$ cvs ci -m "clarify algorithm" hello.c Checking in hello.c; /usr/local/newrepos/myproj/hello.c,v <-- hello.c new revision: 1.22; previous revision: 1.21 done floss$
Then, qsmith can merge those changes into his branch, commit, and, of course, tag:
paste$ cvs -q update -j merged-Exotic_Greetings-1 -j HEAD RCS file: /usr/local/newrepos/myproj/hello.c,v retrieving revision 1.21 retrieving revision 1.22 Merging differences between 1.21 and 1.22 into hello.c paste$ cvs -q update M hello.c paste$ cvs -q ci -m "merged trunk, from merged-Exotic_Greetings-1 to HEAD" Checking in hello.c; /usr/local/newrepos/myproj/hello.c,v <-- hello.c new revision: 188.8.131.52; previous revision: 1.21 done paste$ cvs -q tag merged-merged-Exotic_Greetings-1 T README.txt T foo.gif T hello.c T a-subdir/whatever.c T a-subdir/subsubdir/fish.c T b-subdir/random.c paste$
Notice that jrandom did not bother to tag after committing the changes to hello.c, but qsmith did. The principle at work here is that although you don't need to tag after every little change, you should always tag after a merge or after committing your line of development up to a mergeable state. That way, other people – perhaps on other branches – have a reference point against which to base their own merges.