We'll "race car" is somewhat of an exaggeration, isn't it? Branch support in CVS might be better than VSS, but is rather weak, compared to tools like ClearCase, BitKeeper, Perforce, etc. (In CVS you have to manage repeated updates between branches by yourself, which can be a nightmare. More advanced tools keep a graph of file versions, so they can do much better). Yuval.
-----Original Message----- From: Dewey M. Sasser [mailto:[EMAIL PROTECTED] Sent: Thursday, July 10, 2003 5:42 PM To: [EMAIL PROTECTED] 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
