poi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew C. Oliver" <acoli...@apache.org>
Subject Re: [IMPORTANT] Changes to branch.
Date Wed, 02 Jul 2003 14:17:30 GMT
On 7/2/03 10:02 AM, "Avik Sengupta" <avik@apache.org> wrote:

> 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 :)

No it doesn't.  It just changes it.  You might MERGE THE WHOLE THING over
the other..  Its more dangerous...

> 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. 

+1.  I do what Glen says.
> 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/

Andrew C. Oliver
Custom enhancements and Commercial Implementation for Jakarta POI

For Java and Excel, Got POI?

View raw message