[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2 "how to <> in CVS" questions

From: David H. Thornley
Subject: Re: 2 "how to <> in CVS" questions
Date: Fri, 16 Feb 2001 10:40:45 -0600

Mark O'Brien wrote:
> I didn't what to get into the why's of what I ask. But it is to automate the
> SCM baseline/build/package process. See inline for more info below.
The problem is that people ask "How do I do this?" when it is
difficult or impossible to do exactly "this", or perhaps unwise
for some reason the person hasn't considered.  If we know what
somebody's trying to do in a more general sense, we can be
more helpful.

> > On Thu, Feb 15, 2001 at 09:06:20AM -0500, Mark O'Brien wrote:
> > > I am trying to figure out how to implement an automated process
> > in which,
> > > just prior to checkin approval, the branch is verified. Then
> > after checkin,
> > > the bug number is attached to that new file version.
> >
In this case, we've got a vague description of stuff that
CVS probably doesn't do.  We don't know what you mean by
verifying a branch.  We don't know exactly what you mean by
attaching a bug number, and CVS doesn't make it easy to
attach a specific piece of information *after* checkin.

> I would like every file version to be mapped to at least one bug or
> requirement number. Multiple revisions for the same bug fix is not a
> problem.
It seems to me that having the bug or requirement number in the
checkin comment will satisfy that.  What you can do for that is
write a loginfo program that will check the comment to see
that it has either a bug or a requirement number, and return
nonzero if it doesn't.  With that, you can enforce the idea that
every checkin comes with the number, and it will be associated
with the rev and be reachable by "cvs log".  This has the
property that it doesn't happen without the checkin happening,
so it has similar semantics to "after checkin".

> > If you trust your developers enough to write code, then they should be
> > smart enough to do something like add a line of comment to the commit
> > message, like "BUG #123" and you could have something on the backend that
> > will notice this in the message, and mark the bug as fixed in the bug
> > tracking system.
> Comments are useless to SCM, they are purely for develpoments benefit. If
> SCM is looking at comments to determine what to include in baselines/builds,
> then serious process improvement is needed.
And we're back to talking past each other.  What is it that you
need?  Do you need to be able to recreate baselines and builds
(always a good thing)?  Tag them!  That's the CVS way.

So, are you asking how to automatically add a tag with the
bug or requirement number?  That's something CVS won't do by
itself, so you'd have to write wrappers and get your developers
to use them instead of the raw CVS commands.

But why would you want all of those tags?  Particularly since
they can't say what they are.

Suppose file foo.c has two known bugs, one with a bug number
of 1000 and one with a bug number of 1001.  The second bug is
easier to fix than the first, so on Monday somebody checks
in the fix for 1001 while it takes until Wednesday to check
in the fix for 1000.  If you then have two tags, BUG_1000 and
BUG_1001 on the file, what are they good for?  They don't
represent individual fixes, since BUG_1000 has the fixes for
both 1000 and 1001.  They represent a series of fixes, but
don't come in an obvious order (particularly if mixing bug
and requirements numbers).  Any attempt to update to BUG_????
is going to get an unknown collection of changes, which
is not what SCM is about.  And, if you're not going to
use it to update to, why is it any more useful than a comment?

I'm sorry, but I'm making no sense of what you're saying, and
so I can't possibly help you.  If you tell me in low-level
detail what you want, I can probably tell you it can't be done
in CVS (since that's true of most of such questions).  If I
understand what you're trying to accomplish, I might be able
to come up with something appropriate.  Perhaps you could
provide a use case?

David H. Thornley                          Software Engineer
at CES International, Inc.:  address@hidden or (763)-694-2556
at home: (612)-623-0552 or address@hidden or

reply via email to

[Prev in Thread] Current Thread [Next in Thread]