poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avik Sengupta <a...@apache.org>
Subject Re: [IMPORTANT] Changes to branch.
Date Wed, 02 Jul 2003 14:02:03 GMT
I personally prefer tag/merge, primarily becoz it (almost) removes human
frailty (people forgetting to compile at both places) from the chain...
ie, its typesafe :)

But all i strongly care is that we should have an explicit policy that
everybody knows about.. i was about to draft a mail asking for Glen's
opinion on this .. and since he's the build manager, i'll go with his
decision. 

Regards
-
Avik
 

On Wed, 2003-07-02 at 04:03, Glen Stampoultzis wrote:
> 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:
> 
> http://cvsbook.red-bean.com/cvsbook.html#Branches
> 
> Clear as mud?
> 
> -- Glen
> 
> 
> 
> 
> Glen Stampoultzis
> gstamp@iinet.net.au
> http://members.iinet.net.au/~gstamp/glen/
-- 
Avik Sengupta <avik@apache.org>


Mime
View raw message