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" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, July 10, 2003 12:41 PM Subject: Re: Update versions > "Giovanni Giazzon" <[EMAIL PROTECTED]> 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 > [EMAIL PROTECTED] > --- > 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 > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs _______________________________________________ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
