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. [EMAIL PROTECTED]
| | /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
- RFC 1925 (quoting an unnamed source)
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
