[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: to branch or not to branch
From: |
Eric Siegerman |
Subject: |
Re: to branch or not to branch |
Date: |
Sat, 16 Jun 2001 16:03:34 -0400 |
User-agent: |
Mutt/1.2.5i |
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)