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:28:27 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 :)
> > 
> 
> No it doesn't.  It just changes it.  You might MERGE THE WHOLE THING over
> the other..  Its more dangerous...

Yeah, but i/we wont be doing it, only Glen :)


> 
> > 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/
-- 
Avik Sengupta <avik@apache.org>


Mime
View raw message