james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Serge Knystautas <ser...@lokitech.com>
Subject Re: Updating both branches
Date Tue, 07 Jan 2003 23:28:13 GMT
Danny Angus wrote:
> I think change the HEAD and merge into the branch.
> or add to HEAD and then branch the new file with the same branch name.
> But thats just an informed guess, someone else may have a firmer grasp..
> d.

For binary files and most of the changes we're making now, we don't 
really need to merge.  As long as we can continue to do this, the 
better.  If we really get into this, I would suggest we push for a 
release of HEAD as 2.2 or an early non-contentious 3.x release and 
branch again for another stabilization.

But if you need to merge, here are two excerpts from a CVS guide:
Merging an entire 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".

Consider this revision tree:

+-----+    +-----+    +-----+    +-----+
! 1.1 !----! 1.2 !----! 1.3 !----! 1.4 !      <- The main trunk
+-----+    +-----+    +-----+    +-----+
                 !   +---------+    +---------+
Branch R1fix -> +---! !----! !
                     +---------+    +---------+

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, 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 Conflicts 

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"

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 -> +---! !----! !
                     +---------+    +---------+

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 -> +---! !----! !----! !
                     +---------+    +---------+    +---------+

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 -j R1fix m.c    # Merge changes from to the
                                       # head of the R1fix branch

The problem with this is that you need to specify the 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

Serge Knystautas
Loki Technologies

To unsubscribe, e-mail:   <mailto:james-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:james-dev-help@jakarta.apache.org>

View raw message