Re: Question about version numbers.

[Greg A. Woods]

[ On , November 7, 2001 at 18:24:35 (GMT), address@hidden wrote: ]
> Subject: Re: Question about version numbers.
>
> And, all too often (but not often enough to make it worthwhile checking
> for first or routinely), someone ends up working in a stale branch,

That suggests there's something lacking in how your users make use of
branches.

The best way to work with branches is to ensure the name of the top
directory you create to check out a branch should include both the
module name and the branch name.  I don't know if it's documented
anywhere, but I always thought it was self-obvious.  For example:

        cvs co -r FOO-BRanch -d mymodule.foo-br mymodule

Then all it takes is a 'pwd' to find out what branch and module you're
working on at any given time (or maybe you even have your pwd in your
window title as I do...).

I do know that the documentation recommends using "cvs update -A" to
convert an existing working directory from one branch to another.  I've
always recommended rather strongly against doing this because it is very
easy to make a mistake when doing it.  Always use "cvs release -d" if
you want to get rid of an old working directory and then check out a new
working directory from scratch.  If this is too time consuming then your
modules are too big (or your filesystems are too slow :-).

> or CVS gets confused and we get mixed branches and/or sticky-tags that
> provides all sorts of fun with inconsistent state.

I can't even begin to imagine how that could happen.....  (except
perhaps if you use "cvs update -A" incorrectly)

> Stuff that would
> stand out if, embedded in the file, was the last-set tag and the delta.

Embedding versioning information in unfrozen files is far more likely to
cause errors!

If I had my way I'd have decreed that CVS never expand any keywords in
the working directories, just as SCCS does.  There was, IIRC, even a
short period of time back before the release of 1.4 where this was even
considered to be a default mode of operation, but too many people were
too accustomed to using RCS for it to be accepted.

Of course you can do this anyway, but I'm too lazy to do it, and I'm
sure enough of my own development process that I don't expect I'll ever
make any mistake[*].  The way you'd do this is set a "sticky" -kk option
on checkout by putting the following in your ~/.cvsrc:

        co -kk -d -P

[*] I'm sure of my process because I've actually implemented checks to
ensure that I don't screw up!  ;-)   My commitinfo calls a script that
verifies there is a $Id line near the top of every file and then
validates the revision number in that file matches the expected ancestor
revision for the file (if the file is _not_ in a vendor-branched
module).  In the end I think it gets in the way far more often than it
helps though.  I also do a majority of my CVS use with vendor branched
modules, which means I check them out with '-ko' and never put my own
locally expanded keywords in the locally modified files.

Hmmm.... maybe I'll start using 'cvs co -kk' on my locally mastered
projects and just get rid of that silly $Id validation crap.....

> >> The $Name$ keyword only works with an export, so far as I can tell. 
> >
> > Yes, as it should....  You do not really want to expand $Name into
> > working directories.  It's meant to be an indication of a frozen
> > release.
> 
> But I don't work with frozen releases. I make 'em, export 'em, and then
> move on. 

But that's the whole point.  You're supposed to export a release
(i.e. freeze it), before you do anything with it outside of a working
directory where you've got full access to its current state and history!

Just make sure you use 'cvs export -kv' to really freeze the keyword
values permanently.

Do not ever copy any files (source or product) from a working directory
and use them for anything where they might be confused with any files
from any other working directory!

> I /do/ want to have a way to look at the file and *see* what was the
> latest tag, and how many changes have been made since then, when all
> I have is someone bringing me a printout of the code they're having
> a problem with.

Don't use paper!  Seriously!  Always work online in the relevant working
directory!  If someone really needs paper to work with then they can use
it, but they must only use it privately and never share it.  Paper has
no history or state w.r.t. the repository!

> (Or if I sit down at their machine, and start looking
> at what they're working with. Since it's not my machine or account, 
> using the cvs commands to investigate isn't practical.)

Don't use their account (or their machine)!  Login as yourself.  That
way you won't accidentally change anything in their directory either.

> I can indicate /frozen/ releases with appropriate naming conventions,
> which will magically solve all of my problems *anyway*, right? 

Exactly.  Just remember to use 'cvs export -kv' to ensure the keyword
values really are "frozen".

> > Most of this keyword expansion business is highly over-rated anyway.
> > All you really need and want are the revision Id nubmers themselves and
> 
> It Has Been Declared That Revision ID Numbers Are Not Meant For Humans.

You misunderstand.  Read the rest of the sentence again:

> > from there you can always deduce everything else that's relevant by
> > using them as an index into the "cvs log" output for the given file.

Revision Ids are simply indexes into the repository.  Use them only for
that purpose.

> Deducing everything that's relevent through five minutes of using
> cvs status and cvs log is four minutes and fifty-five seconds of
> wasted time.  I'm certainly not going to be able to make that fly
> with a developer who still isn't comfortable with 'cvs commit'.

You're not making effective use of your tools!  :-)

(oh, and don't forget 'cvs annotate', or it's equivalent in PCL-CVS,
etc. either -- it's very very very useful!)

> Yeah, we're using CVS. If we had a REAL software development process,
> we'd be using a proprietary, commercial version control system mandated
> by management, over the protestations of the developers, but with backing 
> to have training for all developers and to enforce Good Behavior.
> 
> Alas, that's not the case.

Why not?  You should be able to define a proper and appropriate and
consistent software development process that makes use of CVS for
version control.  Many others have.  :-)

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>