Re: Question about version numbers.

[stremler]

Greg A. Woods <address@hidden> wrote:
> [ On , November 6, 2001 at 19:39:21 (GMT), address@hidden wrote: ]
>> Subject: Re: Question about version numbers.
>>
>> How can I get the last-set tag, plus delta from that tag, into my
>> development code?
>
> I'm not sure what you mean here.  Sounds like all you need do is run
> "cvs update"!

Um, no.

Since The Authorities That Be have declared that using CVS/RCS numbers
is Bad Practice, what are the alternatives?  "Use Tags" we are told,
"That Is The Way You Idiots Should Do It Anyway".

So we use tags. They don't help, because we don't develop in an exported
tree. Ever. We also don't develop in just one branch.

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, or
CVS gets confused and we get mixed branches and/or sticky-tags that
provides all sorts of fun with inconsistent state. Stuff that would
stand out if, embedded in the file, was the last-set tag and the delta.

>> 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. 

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. (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.)

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

>> Something along the lines of a $Branch$ and $Tag$ keyword (that might
>> expand to something like $Branch: 1.1.1.1$ and $Tag: cvs1-9$) would 
>> be nice...
>
> If your tag naming scheme is flexible and complete enough there's no
> need for such additional features.

It doesn't matter how flexible my scheme is when I have to jump
through hoops to find out what I want to know. (Hm. A $Tag$ should
expand to something like "$Tag: cvs1-9: 1.2.3.4$ to provide delta
information.  That is, if there isn't a better way.)

Worse, some of the folks using the same tree -- some of them newbies to
CVS -- can't see the tags, and get confused about which branch they're
supposed to be working in.  (And no, I can't train, discipline, or
even shout at these people. Which is okay, because this isn't a continual
problem -- only occassional, but annoying nonetheless.)

> 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.

> 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.

So shall I go back to putting $Log$ into the source files?

Oh, wait, that's not kosher either.

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'.

> If you think you need tags expanded in your working directories then
> there's something seriously wrong with your overall software development
> process.

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.

The software development process I'm in may not be great, but it's
better than a lot, and especially, it's better than before (which 
was Version Control Using PKZip[tm]).  Waving you hands and saying
that "desiring feature X means that you're doing something wrong"
*may* be correct, but it's not useful.

If CVS is so constraining on software development processes, they why
doesn't the Cederqvist manual specify a software development process
that *does* work with CVS?

-- 
      "Why yesh offisher I've been drinking but thatsh wash owersh ago."
 -----------------------------------------------------------------------------
  Stewart John Stremler                            address@hidden