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

[Vadim Zeitlin]

On Wed, 15 Nov 2006 18:11:46 +0000 Greg Chicares <address@hidden> wrote:

GC> The main trunk contains a release candidate that's being tested
GC> right now, so I've created a new branch for development in the
GC> interim. I'm thinking that we ought to do this regularly, using
GC> names generated as 'branch-YYYYMMDD' for consistency (it seems
GC> unnecessary to create two branches on the same day),

 I don't see why shouldn't it be possible to create 2 branches per day, for
example if 2 persons start working on different subprojects simultaneously.
And while this could be fixed by using "branche-YYYYMMDDHHMMSS" format, I
also believe that symbolic names for branches are more useful than
timestamps as they explain much better what changes were done on that
branch.

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

 Yes, it sounds good for the relatively big projects, but I'd just like to
use descriptive branch names for them. I hope it would still be possible to
apply small patches (directly or after your review) to HEAD as creating a
branch for each of them would be too much trouble and not worth it.

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

 I don't know if it's best but the common practice is to leave it alone.
And while this is the path of the least resistance (which is usually
suspicious :-) I don't see how could this result in any problem so why not
just do it like this. I.e. not do anything.


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

 I always used HEAD for it but I admit I didn't give much thought to the
problem. MAIN is not a tag at all though (try using it as argument to -r
option -- it won't work) but a pseudo-tag at best so I prefer avoiding it.

GC> Let me start with an example:
GC> 
GC> [1] $Id: ledger_text_formats.hpp,v 1.5 2006/01/29 13:52:00 chicares Exp $
GC> [2] $Id: ledger_text_formats.hpp,v 1.5.2.11 2006/11/08 00:42:55 etarassov 
Exp $
...
GC> I think the resolution is that the meaning of 'HEAD' depends on
GC> context:
GC>  - in the main trunk, 'HEAD' = [1]
GC>  - in the branch,     'HEAD' = [2]
GC> But is that right?

 No. Just do "cvs up -rHEAD ledger_text_formats.hpp" from anywhere (i.e.
from a branch or not) -- it will always retrieve the revision 1.5. So IMHO
there is just an error in the manual. But, of course, cvs does have its
quirks so maybe I'm missing something.

 Regards,
VZ