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

[David H. Thornley]

Mark O'Brien wrote:
> 
> Okay, here's what I would like to do.
> 
> Short: Create and automated baseline/build/package system, that executes
> after being given bugs that have been fixed.
> 
Thanks.  This makes things easier.

> Detail:
> 
> 1) Need to have CVS ask for bug number prior to checkin. Validate the number
> with the bug track tool, get the state of the bug and branch to be fixed on.
> Then validate the state (is the bug in a dvlp state or is it in a
> test/closed state?) and the branch (make sure the bug has been fixed on the
> correct branch). Then allow or disallow checkin.
> 
I don't think there's anything built-in that will allow this.
You can get the file name, with commentinfo, or the log message
with loginfo, but not both, and I don't know that either can
reliably get you the branch.

> 2) Either before or after checkin, somehow associate the validated bug
> number with the version of the file in a way that will allow 3). Yes, a
> dvlpr can and the bug number, but what if the number is typed wrong, what if
> the dvlpr leaves it out.
> 
The developer can always mistype the bug number.  Aside from
checking that it's valid, and possibly that the bug track tool
thinks this file is one that might reasonably be altered, I
don't think there's much you can do about that.  You can reject
if the developer leaves it out entirely.  You can do this with
loginfo.

> 3) Given a tag for the previous baseline A (tag on all files that represents
> the last build), and bug numbers completed since last build, construct
> baseline B from A by adding file changed for the given bug numbers. Parsing
> each ,v file or a cvs log output to find bug numbers and than figure out
> version numbers is not all that attractive.
> 
I've parsed cvs output before, and, yes, it isn't all that attractive.
However, I don't know of another way to put such information on
a CVS entry.

I think what you're going to have to do is write wrappers for
CVS that will do the CVS processing and keep track of the external
information some other way.  This means that you've got to keep
your developers from using "cvs ci" directly, somehow or another.
Possibly the wrapper can set some sort of flag that commitinfo
can test for, and abort the checkin if it's being done directly.

> You right, maybe I can't do what I want with CVS. But I don't have a choice,
> I have to automate the process, make it robust and have to use CVS.
> 
You can use CVS inside the tool, but you're going to have to
wrap functionality around it.  I don't see any other way.

-- 
David H. Thornley                          Software Engineer
at CES International, Inc.:  address@hidden or (763)-694-2556
at home: (612)-623-0552 or address@hidden or
http://www.visi.com/~thornley/david/