Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

<jason_> any svn users who are familiar with the fly fishing technique?
<jason_> just looking for a little advice on working with branches
<chipig> fly fishing and branches?
<rooneg> i can give advice on working with branches, but i have no clue what you mean by "fly fishing technique" in that context
<jason_> http://cvsbook.red-bean.com/cvsbook.html#Going%20Out%20On%20A%20Limb%20(How%20To%20Work%20With%20Branches%20And%20Survive)
<jason_> rooneg, do you typically work on trunk and merge into the branch periodically or right away?
<rooneg> well, it depends what kind of branch you're talking about. is it a release branch? a maintenance branch? a feature branch?
<jason_> in this case a release branch
<jason_> well, we release from this branch
<rooneg> well, for subversion itself we use a technique like this. when we're ready to start preparing for a release we branch off of the trunk.
<jason_> http://svn.apache.org/viewcvs.cgi/maven/components/branches/maven-2.0.x/
<rooneg> any last minute modifications to the branch happen there (updating change lists, version numbers, etc), then we cut a release candidate.
<rooneg> at this point trunk development continues as usual
<rooneg> there is now a soak period, where the RC is tested. if bugs are found they are fixed on the trunk and then proposed for merging back to the branch.
<rooneg> when we've got enough fixes merged in that a new RC is justified we roll a new RC off the release branch
<rooneg> (rolling an RC means tagging it as well, FWIW)
--> jesse (n=jesse@216-161-72-109.omah.qwest.net) has joined #asf
<rooneg> eventualy one of our RCs is declared final, and we roll the final release with only a version number change relative to the last RC
<rooneg> the release branch (i.e. branches/1.2.x or branches/1.3.x) sticks around and we do basically the same thing for the next release.
<rooneg> the important thing is that all changes go into the trunk first, then get merged into the release branch as needed, so no changes ever get dropped by mistake
<jason_> cool, that's what i wanted to hear
<jason_> thx for the advice
<jason_> what's your name btw? just so i remember (smile)
<rooneg> no problem
<rooneg> Garrett Rooney (wink)

More notes from Garrett and Paul Querna

<jason_> rooneg, do you use anything like that svnmerge.py script?
<jason_> is that a useful script, i just saw it in the svn contrib section
<rooneg> jason_: personally, no, i've never used it, but some svn developers do
<rooneg> it's really more useful for things like feature branches, where you intend to merge all changes from one branch into another.
<rooneg> so if i created a branch to work on a new feature, and i want to periodically merge the changes from trunk into it, to keep me up to date, svnmerge.py would help a lot
<rooneg> not sure how well it deals with cherry picking individual revisions though, like we do for release branches.
<jason_> are there many cases where changes would originate in a branch?
<jason_> does that ever happen much?
<chipig> not for release branches

  • jason_ ordered the book, one click is evil!
    <chipig> only if for whatever reason, the code in the release branch, doesn't exist in the trunk. IE with a depricated module.
    <jason_> so from trunk to branch is the general rule, cool
    <jason_> chipig: what's your name?
    <rooneg> yeah, that's the general idea, it simplifies things, and ensures that you never accidentally fix a bug in an older version but not in a newer one
    <rooneg> of course, development branches (like a branch to implement a particular feature) are diffeent, the whole point there is to implement some new feature, then merge it back to trunk later.
    <quasi> jason_: there's this cool feature in irc clients - /whois (wink)
    <jason_> well, you learn something new every day!
    <jason_> well, i might guess it's mads toftum because your name has popped up on mailing lists but that result returned still isn't all that clear
    <chipig> jason_: paul querna...
    <jason_> chipig's came up with a full name
    <quasi> jason_: correct
    <jason_> cool, thanks for the advice. will go directly into maven development process doco.