[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Update versions
From: |
Giovanni Giazzon |
Subject: |
Re: Update versions |
Date: |
Thu, 10 Jul 2003 14:51:13 -0300 |
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
- Update versions, Giovanni Giazzon, 2003/07/08
- Re: Update versions, Larry Jones, 2003/07/08
- Re: Update versions, Giovanni Giazzon, 2003/07/09
- Re: Update versions, Larry Jones, 2003/07/09
- Re: Update versions, Giovanni Giazzon, 2003/07/09
- Re: Update versions, Larry Jones, 2003/07/09
- Re: Update versions, Dewey M. Sasser, 2003/07/10
- Re: Update versions, Terrence Enger, 2003/07/10
- Re: Update versions,
Giovanni Giazzon <=