poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Glen Stampoultzis <gst...@iinet.net.au>
Subject [IMPORTANT] Changes to branch.
Date Tue, 01 Jul 2003 22:33:31 GMT

It's time to make explicit how we want the branches to work.

So far I've been committing to both places (where appropriate).  I've been 
doing this because it's the most flexible method.  It does have it's 
downside however (you have to do more work).

The alternative is to carefully mark CVS merge points and use cvs update -j 
TAG1 -j TAG2 to merge periodically.  This sounds good in practice but 
suffers from a number of difficulties:

         1. You have to be very careful with your tagging.
         2. It assumes you want everything in the BRANCH to go back to the 
head.  This might not be the case.
         3. People often commit to the head by mistake which messes up the 
whole auto-merge thing.

So my preference (in this particular instance) is to make the changes in 
both places. There are techniques you can use to help make this easier such 
as making a diff before doing the first commit.

This is open to debate if you have a strong opinions either way.

To Avik:  This means that you'll need to apply those changes you just 
committed to the head as well.

Here's a email I sent to Danny a little while ago which may be of some help:


Branches are one of the more difficult aspects of CVS (and most version 
control systems for that matter).

There are a few approaches:

1. You can commit all your branch stuff to the branch then merge the 
changes back periodically using the -j option in cvs update.  This requires 
you to be fairly methodical with your tagging.  The first merge is 
generally easy.  The problem is that following merges default to merging 
everything again (generating conflicts).  To get around this you use  tags 
to keep track of the last time you joined.  Another problem with this 
approach is that there may be things you do not wish to merge.  It's pretty 
hard to be selective.

2. You can make changes in both the trunk and the branch by using patch to 
apply the diffs.  The email commit files would be perfect for this except 
for the fact that the lines tend to be wrapped from being sent through the 
mail system.  You can could generate a diff file easily enough just by 
using cvs diff -u before you commit.  Or if you forgot to do that by 
specifying a date (eg: cvs -q -z9 rdiff -D "5 minutes ago" 
jakarta-poi).  This method is a little painful because you do things twice 
but it's probably the easiest to understand.

3. The other option is to manually make the changes in both the branch and 
head.  Not a nice option and it's every easy to make mistakes.

There is some good material on branching and merging here:


Clear as mud?

-- Glen

Glen Stampoultzis

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message