Next: , Previous: Merging Repeatedly Into The Trunk, Up: Going Out On A Limb (How To Work With Branches And Survive)

The Dovetail Approach – Merging In And Out Of The Trunk

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 qsmith's.

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

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:; previous revision: 1.21
     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

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.

Karl Fogel wrote this book. Buy a printed copy via his homepage at

copyright  ©  January 18 2019 sean dreilinger url: