[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[lmi] New interim branch 'branch-20061115', and some cvs questions
From: |
Greg Chicares |
Subject: |
[lmi] New interim branch 'branch-20061115', and some cvs questions |
Date: |
Wed, 15 Nov 2006 18:11:46 +0000 |
User-agent: |
Thunderbird 1.5.0.4 (Windows/20060516) |
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'.
- [lmi] New interim branch 'branch-20061115', and some cvs questions,
Greg Chicares <=