Re: Update versions

[Giovanni Giazzon]

Hi Dewey,
first of all, thanks for the help.
The strategy I'm using today is similar to the "Change Control" approach
(with some mistakes like set the development to a branch). It seems the best
strategy for my project right now, so I'll move the development to the main
trunk and I'll be using branches just for bug fixing.

Regards,
Giovanni Giazzon



----- Original Message -----
From: "Dewey M. Sasser" <address@hidden>
To: <address@hidden>
Sent: Thursday, July 10, 2003 12:41 PM
Subject: Re: Update versions


> "Giovanni Giazzon" <address@hidden> writes:
>
> > Yes, I'm a little confused about branches.
>
> Let me describe how I've used and seen branches.  That might help you
> out.
>
> > Sorry about the misunderstanding. I'm coming from SourceSafe...
>
> Ouch!  Congratulations.  You've just traded in your bicycle for a race
> car.
>
> First of all, SourceSafe (last I used it, at least) handles branches
> very poorly.  Don't apply any of the branch procedures you learned
> dealing with SourceSafe to CVS.  Start fresh.
>
>
>
> OK, here goes.
>
>
>                    A branch is a management problem
>
> Unless you're using a very poor source control tool (SourceSafe comes
> to mind) then the problems you face from the management of changes far
> outweigh their implementation.
>
> No matter how you slice, if you have two parallel branches and you're
> merging changes back and forth you will have a very difficult system
> to manage and as the branches diverge (and I've never seen them *not*
> diverge) automated tools will decrease in value managing this task.
>
> In short:  2 is greater than 1, and working on two different (though
> closely related) source bases is more work than only 1.  Branches are
> more work.  Branches are not free.  They can, however, allow you to
> partition your work so you can better deliver it.
>
> HOLD IT!  By "branches are not free" I mean the *concept*, not the
> tool.  If you try to implement the concept without doing it in the
> tool you're *NOT* saving any work -- you're costing yourself even
> more.
>
>
>
>                 Using Branches in Software Development
>
> You first have to decide on your branch strategy.  Branch strategy
> basically consists of when to merge and how to track the changes and
> is driven by the goals of your branch.  Your goals are for bug fixing.
> I'll presume you're doing simple bug fixing (rather than architectural
> changes).  I've seen #1 and #4 used successfully (but I'm presenting
> the others so you have an idea of *why* #1 and #4 are good ideas).
>
> Some strategies that come to mind:
>
> 1) "Simple" strategy.
>
> You make changes and release on the "HEAD" (main trunk).  When it
> becomes obvious that you must fix a bug in a previous release, *if*
> the main trunk is not suitable for said bug fix then you
>
>    a) Create a branch at the release point
>    b) Make bug fixes on the branch
>    c) Make a release from the branch
>    d) merge all changes from the branch back into the main trunk
>
> Advantages:
>              o Simple.
>              o No unnecessary branches.
> Disadvantages:
>              o Inconsistent:  some releases are from branches, some
>                from the main trunk.
>              o If you have to produce another release from the branch
>                the merge becomes more complex.
>
> Assumptions:
>              o Use this strategy when you have a relatively small
>              project where
>                 a) it is not terribly likely you'll have to make
>                    bug fixes off of old code (you can always
>                    incorporate a bug fix into the "next" version)
>                 b) (not obvious) You never want to check in code that
>                    won't be in the next release.
>
> Comments:  I've used this.  Each release is a special case that you
> have to figure out how to branch it, but it's not too difficult.  Very
> suitable to single developer work.
>
> 2) "Absolute Chaos" strategy
>
> This is what you get when you push the simple strategy too far.  In
> other words, you violation the assumptions behind the simple strategy.
>
> Basically, "Absolute Chaos" starts the same way, but...
>
>    a) Create a branch at the release
>    b) Make some bug fixes on the branch for that release.
>    c) 1 or more of
>          Copy some bug fixes from the main trunk to the branch.
>      or  Make some local work arounds on the branch that you *do not
>          want* in the main trunk.
>
> Advantages:
>         o You can claim to management that you're doing work on
>           "infrastructure" tasks
>         o Actual response time to get a bug fix checked in is fairly
>           small.
>         o You don't have to make everyone "do it the right way"
>         (sometimes necessary when you have cowboy coders)
>
> Disadvantages:
>         o Chaos of the merge situation seriously affects quality
>         o Release time or content actually suffers.
>
> Assumptions:
>         o Why this happens:
>            a) "branches are free"
>            b) Changes are being made in both places without measuring
>               their impact
>
> The problem here is that each of the branch and the trunk have pieces
> you need and pieces you don't want, so you have to merge them manually
> and inspect each piece.  Hire extra QA staff and treat them *really*
> well.
>
> Comments:  I've seen this.  Enough said.
>
>
> 3) "Warden" strategy
>
> This strategy is characterized by "no one check in code that shouldn't
> go into XXX release".
>
> Same scenario as #1, but the reaction in the "Warden" strategy is to
> *not* create a branch until it's absolutely necessary (meaning
> customer lawsuits or some such) to do so.  Then a branch is typically
> created that's so big it might as well be a separate project.  If
> you're Oracle you have a good reason for doing this.  Most of us don't.
>
>   a) Bug fixes are developed separately for the separate "branches".
>      each developer must see that their bug fix gets in to all
>      branches.
>   b) As release time on a branch approaches check ins that are not
>      necessary for the release are either discouraged or forbidden.
>   c) Any *absolutely necessary* fix that does not fall into the
>      leading each of one of the branches ends up being a "customer
>      special" release.  (Meaning a developer checks out the released
>      code, applies the bug fix, probably does a local build and send
>      the code directly).  Changes of this nature are effectively
>      uncontrolled.
>
> Advantages:
>         o Works when there is very poor tool support for branching
>         o Works when developers "don't get" the concept of branching
>
> Disadvantages:
>         o *Much* more work wasted putting the same fix in multiple
>           places.
>         o Developers often idle waiting for a time they can check in.
>         o Still have to track individual changes.
>
> Assumptions:
>         o Tool support is very poor (SourceSafe anyone?)
>         o Customer base *extremely* sensitive to any changes (complex
>           library)
>
> Comments:  I've seen this one also.  It gets reasonably stable code
> out the door but isn't very efficient and really frustrates developers.
>
> 4) "Change Control" strategy
>
> I've used this successfully in the past.  It's an extension of the
> simple strategy to work around the assumptions of that strategy.
>
> In this scenario, branching actually starts much sooner but is well
> controlled.
>
>    a) All development and bug fixing is done on the main trunk
>    b) Some time before a release you create a "change isolation
>       branch".  The release will be made off of that branch.
>    c) Once the change isolation branch is made all changes to that
>       branch are first made on the main trunk and then merged to the
>       isolation branch.
>    d) Any work arounds which apply *only* to the given release can be
>       made on the release branch directly.
>    e) After the release is done the branch is abandoned (unless you
>       need a further point release).
>    f) If another release is needed on a previous branch you just fix
>       it, merge it and make the release.
>
> Advantages:
>         o Good change control -- you know exactly what's going in to
>           each release
>         o Merge simplicity -- all merges happen one direction only
>         o No "lockdown period" -- new development can occur on the
>           main trunk without affecting the release.
>         o All releases are consistent in their branch origin:  they're
>           all from a branch.
>         o No confusion about accidentally merging "branch throw-away"
code.
>
> Disadvantages:
>         o For very old releases the "patch" to the main trunk might
>           not work against the branch.  You're then reduced to the
>           first half of the "Warden" strategy.
>         o It is sometimes difficult to properly repeat bugs in the
>           "main" trunk where original work needs to be done.
>
> Assumptions:
>         o Trunk development should continue during release
>         o Trunk is sufficiently close to branch that bug fixes are
>           valid (major architectural work might violation this
>           assumption in which case the fix becomes "branch throw
>           away")
>
> Comments:  I've used this one and found it to be very nice within it's
> assumptions.
>
> 5) The "Linux kernel" strategy
>
> I don't know much about this strategy beyond the user visible results:
> i.e. that the claim the ".even" release are fairly stable and the
> ".odd" releases aren't, and that features are occasionally
> "backported" from e.g. 2.5 to 2.4.
>
>
> Hope this helps.
>
> --
> Dewey M. Sasser
> address@hidden
> ---
> The reason we hold truth in such respect is because we have so little
> opportunity to get familiar with it.
> Mark Twain
>
>
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs