GNU Info

(cvsbook.info)The Dovetail Approach -- Merging In And Out Of The Trunk

---

Next: The Flying Fish Approach -- A Simpler Way To Do It Prev: Merging Repeatedly Into The Trunk Up: Going Out On A Limb (How To Work With Branches And Survive)

---

Enter node , (file) or (file)node

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
     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: 1.21.2.1; 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.