RE: Update versions

[Yuval Rotem]

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:address@hidden 
Sent: Thursday, July 10, 2003 5:42 PM
To: address@hidden
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