You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@poi.apache.org by Glen Stampoultzis <gs...@iinet.net.au> on 2003/07/02 00:33:31 UTC
[IMPORTANT] Changes to branch.
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/
Re: Subvert? Re: [IMPORTANT] Changes to branch.
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
Sound's very nice. I hope subversion hurries up and matures. :-)
At 06:10 AM 4/07/2003, Greg Stein wrote:
>On Thu, Jul 03, 2003 at 09:51:51AM -0400, Andrew C. Oliver wrote:
> > On 7/2/03 7:51 PM, "Glen Stampoultzis" <gs...@iinet.net.au> wrote:
> > > At 12:28 AM 3/07/2003, you wrote:
> > >
> > > Ahh but it isn't as simple as that... The problems are these:
> > >
> > > 1. Someone commits stuff to the head the realizes their mistake and
> commits
> > > to the branch. Now i'm faced with the problem of merging changes back
> > > except for those particular changes. Can't be done that I know
> > > of. Changes aren't atomic and CVS and I can't pick and choose which ones
> > > to merge back.
> > > 2. Someone commits stuff to the branch that they don't want to go
> back into
> > > the head. Here I face the same problem as with 1. I can't pick and
> choose
> > > which changes to merge.
> > >
> > > You see the problem?
> > >
> > > BTW, does anyone know enough about subversion as to whether it lets you
> > > pick and choose which commits to merge? I believe bitkeeper allows this.
> >
> > No but I know who does...
>
>Heh.
>
>Subversion commits are atomic changesets. You can select which changes to
>merge into the trunk or a branch or wherever. Bitkeeper has more flexibility
>in selecting changesets, but for the use cases you describe, Subversion is
>*very* capable.
>
>Note that Subversion uses a global revision number. Each commit generates a
>new revision. It is the deltas between these revisions which are effectively
>your change sets. These revision numbers make it very easy to select what to
>merge. Below are examples for your two use cases:
>
>Case 1:
>
>[.../trunk]$ svn commit -m "super duper changes"
><output>
>Committed revision 1234.
>[.../trunk]$
>
>Oh damn! Wrong branch. Let's switch over to the branch and commit this.
>
>[.../trunk]$ svn switch http://svn.apache.org/repos/asf/branches/FOO
><output>
>
>This switched the working copy to the branch. Much like 'cvs up -r FOO'.
>
>[.../trunk]$ svn merge -r1233:1234 http://svn.apache.org/repos/asf/trunk
><output>
>[.../trunk]$ svn commit -m "merged super duper changes from trunk"
>
>
>Case 2:
>
># grab 1100 thru 1300, except revisions 1200 and 1210
>[.../trunk]$ svn merge -r 1100:1199
>http://svn.apache.org/repos/asf/branches/FOO
><output>
>[.../trunk]$ svn merge -r 1200:1209
>http://svn.apache.org/repos/asf/branches/FOO
><output>
>[.../trunk]$ svn merge -r 1210:1300
>http://svn.apache.org/repos/asf/branches/FOO
><output>
>[.../trunk]$ svn commit -m "merged changes from branch FOO"
>
>
>There ya go...
>
>Cheers,
>-g
>
>--
>Greg Stein, http://www.lyra.org/
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: poi-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: poi-dev-help@jakarta.apache.org
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
Re: Subvert? Re: [IMPORTANT] Changes to branch.
Posted by Greg Stein <gs...@lyra.org>.
On Thu, Jul 03, 2003 at 09:51:51AM -0400, Andrew C. Oliver wrote:
> On 7/2/03 7:51 PM, "Glen Stampoultzis" <gs...@iinet.net.au> wrote:
> > At 12:28 AM 3/07/2003, you wrote:
> >
> > Ahh but it isn't as simple as that... The problems are these:
> >
> > 1. Someone commits stuff to the head the realizes their mistake and commits
> > to the branch. Now i'm faced with the problem of merging changes back
> > except for those particular changes. Can't be done that I know
> > of. Changes aren't atomic and CVS and I can't pick and choose which ones
> > to merge back.
> > 2. Someone commits stuff to the branch that they don't want to go back into
> > the head. Here I face the same problem as with 1. I can't pick and choose
> > which changes to merge.
> >
> > You see the problem?
> >
> > BTW, does anyone know enough about subversion as to whether it lets you
> > pick and choose which commits to merge? I believe bitkeeper allows this.
>
> No but I know who does...
Heh.
Subversion commits are atomic changesets. You can select which changes to
merge into the trunk or a branch or wherever. Bitkeeper has more flexibility
in selecting changesets, but for the use cases you describe, Subversion is
*very* capable.
Note that Subversion uses a global revision number. Each commit generates a
new revision. It is the deltas between these revisions which are effectively
your change sets. These revision numbers make it very easy to select what to
merge. Below are examples for your two use cases:
Case 1:
[.../trunk]$ svn commit -m "super duper changes"
<output>
Committed revision 1234.
[.../trunk]$
Oh damn! Wrong branch. Let's switch over to the branch and commit this.
[.../trunk]$ svn switch http://svn.apache.org/repos/asf/branches/FOO
<output>
This switched the working copy to the branch. Much like 'cvs up -r FOO'.
[.../trunk]$ svn merge -r1233:1234 http://svn.apache.org/repos/asf/trunk
<output>
[.../trunk]$ svn commit -m "merged super duper changes from trunk"
Case 2:
# grab 1100 thru 1300, except revisions 1200 and 1210
[.../trunk]$ svn merge -r 1100:1199 http://svn.apache.org/repos/asf/branches/FOO
<output>
[.../trunk]$ svn merge -r 1200:1209 http://svn.apache.org/repos/asf/branches/FOO
<output>
[.../trunk]$ svn merge -r 1210:1300 http://svn.apache.org/repos/asf/branches/FOO
<output>
[.../trunk]$ svn commit -m "merged changes from branch FOO"
There ya go...
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: [IMPORTANT] Changes to branch.
Posted by Avik Sengupta <av...@apache.org>.
>BTW, does anyone know enough about subversion as to whether it lets you
> pick and choose which commits to merge?
I dont know about that, but i believe one of its key features is that it
remembers whats been merged, so that you dont have to tag at each merge
On Thu, 2003-07-03 at 05:21, Glen Stampoultzis wrote:
> At 12:28 AM 3/07/2003, you 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...
> >
> >Yeah, but i/we wont be doing it, only Glen :)
>
>
> Ahh but it isn't as simple as that... The problems are these:
>
> 1. Someone commits stuff to the head the realizes their mistake and commits
> to the branch. Now i'm faced with the problem of merging changes back
> except for those particular changes. Can't be done that I know
> of. Changes aren't atomic and CVS and I can't pick and choose which ones
> to merge back.
> 2. Someone commits stuff to the branch that they don't want to go back into
> the head. Here I face the same problem as with 1. I can't pick and choose
> which changes to merge.
>
> You see the problem?
>
> BTW, does anyone know enough about subversion as to whether it lets you
> pick and choose which commits to merge? I believe bitkeeper allows this.
>
> Regards,
>
>
> Glen Stampoultzis
> gstamp@iinet.net.au
> http://members.iinet.net.au/~gstamp/glen/
--
Avik Sengupta <av...@apache.org>
Subvert? Re: [IMPORTANT] Changes to branch.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
On 7/2/03 7:51 PM, "Glen Stampoultzis" <gs...@iinet.net.au> wrote:
> At 12:28 AM 3/07/2003, you wrote:
>
> Ahh but it isn't as simple as that... The problems are these:
>
> 1. Someone commits stuff to the head the realizes their mistake and commits
> to the branch. Now i'm faced with the problem of merging changes back
> except for those particular changes. Can't be done that I know
> of. Changes aren't atomic and CVS and I can't pick and choose which ones
> to merge back.
> 2. Someone commits stuff to the branch that they don't want to go back into
> the head. Here I face the same problem as with 1. I can't pick and choose
> which changes to merge.
>
> You see the problem?
>
> BTW, does anyone know enough about subversion as to whether it lets you
> pick and choose which commits to merge? I believe bitkeeper allows this.
>
No but I know who does...
> Regards,
>
>
> Glen Stampoultzis
> gstamp@iinet.net.au
> http://members.iinet.net.au/~gstamp/glen/
>
--
Andrew C. Oliver
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
Re: [IMPORTANT] Changes to branch.
Posted by Glen Stampoultzis <gs...@iinet.net.au>.
At 12:28 AM 3/07/2003, you 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...
>
>Yeah, but i/we wont be doing it, only Glen :)
Ahh but it isn't as simple as that... The problems are these:
1. Someone commits stuff to the head the realizes their mistake and commits
to the branch. Now i'm faced with the problem of merging changes back
except for those particular changes. Can't be done that I know
of. Changes aren't atomic and CVS and I can't pick and choose which ones
to merge back.
2. Someone commits stuff to the branch that they don't want to go back into
the head. Here I face the same problem as with 1. I can't pick and choose
which changes to merge.
You see the problem?
BTW, does anyone know enough about subversion as to whether it lets you
pick and choose which commits to merge? I believe bitkeeper allows this.
Regards,
Glen Stampoultzis
gstamp@iinet.net.au
http://members.iinet.net.au/~gstamp/glen/
Re: [IMPORTANT] Changes to branch.
Posted by Avik Sengupta <av...@apache.org>.
> > 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 <av...@apache.org>
Re: [IMPORTANT] Changes to branch.
Posted by "Andrew C. Oliver" <ac...@apache.org>.
On 7/2/03 10:02 AM, "Avik Sengupta" <av...@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
http://www.superlinksoftware.com/poi.jsp
Custom enhancements and Commercial Implementation for Jakarta POI
http://jakarta.apache.org/poi
For Java and Excel, Got POI?
Re: [IMPORTANT] Changes to branch.
Posted by Avik Sengupta <av...@apache.org>.
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 <av...@apache.org>