[lmi] New interim branch 'branch-20061115', and some cvs questions

[Greg Chicares]

The main trunk contains a release candidate that's being tested
right now, so I've created a new branch for development in the
interim. I'm thinking that we ought to do this regularly, using
names generated as 'branch-YYYYMMDD' for consistency (it seems
unnecessary to create two branches on the same day), and then
merge them into the main trunk as soon as testing is complete.
Non-branch tags for tested releases are 'lmi-YYYYMMDDTHHMMZ',
so we have two different namespaces for these routine tags.

I realize that many projects treat the main trunk as a sandbox
and put actual releases on branches. Our discipline has been
sufficient to keep the main trunk in a releasable state at all
times, however, and that has served our business needs well.

We developed the calculation summary on a branch, then applied
discipline upon merging it. Perhaps similar projects should be
done the same way in the future. They'd be on project-specific
branches--distinct from the routine branches described above,
whose purpose is to keep the main trunk sacrosanct during formal
testing. Does that sound best?

I'm also open to other suggestions.

And I have a couple of general questions about cvs:

- What should we do with obsolete branches?

'libxmlpp_branch' was subsumed into 'gnome-xml-branch', so the
former is no longer of interest. What, if anything, should we
do about it? Leave it alone; remove all its files; or something
else? What's the best practice?

- Is there a concise term for "the main trunk"? 'HEAD'? 'MAIN'?

Let me start with an example:

[1] $Id: ledger_text_formats.hpp,v 1.5 2006/01/29 13:52:00 chicares Exp $
[2] $Id: ledger_text_formats.hpp,v 1.5.2.11 2006/11/08 00:42:55 etarassov Exp $

[1] is the tip of the main trunk.

[2] is the most recent version in the repository. It won't be
merged as such, because I ported it to 'ledger_formatter.hpp'
in the main trunk.

The cvs book
  http://cvsbook.red-bean.com/cvsbook.html
seems confusing on this point:

| The special reserved tag HEAD means the tip of the trunk.

Okay, then HEAD = [1], I guess.

| The special tags HEAD and BASE may be used as arguments to -j;
| they mean the most recent revision in the repository, and the
| revision on which the current working copy file is based,
| respectively.

No, wait: HEAD = [2]? I perceive a contradiction.

I think the resolution is that the meaning of 'HEAD' depends on
context:
 - in the main trunk, 'HEAD' = [1]
 - in the branch,     'HEAD' = [2]
But is that right? Here's a reference that suggests otherwise:

http://www.zope.org/DevHome/CVS/ZopeCVSFAQ
|
| The "trunk" is really not particularly different from any other
| branch in CVS - it can be though of as a sort of default
| "unnamed" branch. It turns out that the trunk does have a name
| of sorts though. The name HEAD is used in CVS to refer to the
| trunk, and can be used pretty much anywhere you would use a
| branch tag name.

and here's another that suggests that the name of the main trunk
is 'MAIN', and that 'HEAD' is not like a branch tag:

http://ximbiot.com/cvs/wiki/index.php?title=CVS_FAQ
|
| "HEAD is not a branch name, did you mean MAIN?"

yet the cederqvist doesn't even mention 'MAIN'.

A rose by any other name would smell as sweet, but technical
terms mustn't be misused. If you're working on a branch and I
say I've committed a change to 'HEAD', you might look for it in
vain at the head of the branch if the place I really committed
it is 'MAIN'.