Re: to branch or not to branch

[Eric Siegerman]

On Sat, Jun 16, 2001 at 05:35:06PM +1000, Matthew Herrmann wrote:
> [when tagging a release] should I use the -b option even if I
> don't need to branch yet?  Most of the time it doesn't happen,
> but I want to have the option open if it's needed.  Can I just
> tag it and then later turn it into a branch?

Effectively yes, though it doesn't work quite like that.  Suppose
you cut a release, and gave it a release (ie. non-branch) tag:
        cvs rtag RELEASE_3_2 module1 module2

Now you need to create a bug-fix branch for that release.  Do
it with:
        cvs rtag -rRELEASE_3_2 -b RELEASE_3_2_BUGFIXES module1 module2

This creates a new branch, RELEASE_3_2_BUGFIXES; the -r option
specifies that the branch point for each file is whichever
revision was tagged with RELEASE_3_2.  This isn't quite "turning
the release tag into a branch", because the original release tag
isn't transformed, but only looked at.

> I know there a size+speed+complexity overhead associated.

Not that significant, probably.  What matters more is the
comprehensibility overhead -- all those extra branches get
confusing unless you're *very* careful to log which ones have
code on them, which have been merged, etc.  So yes, you
absolutely have the right idea: don't create a bug-fix branch
unless and until you need it.

Even if you do at some point want to create a branch immediately,
you should also create a release tag at the same time.  This is
how you'll be able to get back the exact sources that went into
the release -- a branch tag won't be as helpful there.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)