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

[Todd Denniston]

"David H. Thornley" wrote:
> 
> 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.
> 
Getting the bug number is not a problem with rcsinfo and verifymsg, and then
validating it can with some command line accessible tool on unix during the
verifymsg phase.
This command line tool could also do the validation of the state.
Use verifymsg, and rcsinfo to force these things.

look at http://mail.gnu.org/pipermail/info-cvs/
for "Re: Verifymsg on branches?" on 11/22/00
I posted an approximation (sanitized version) of my whole verifymsg/rcsinfo set,
you could look at this for more information.  Note: the verification I do on the
bug number (aka PCR#) is very simplistic but this is what you would replace with
a more intelligent verify routine.

Branches are a different matter, I can not say if that can be done or not as I
have not done anything with branching at all yet.

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

when you do a checkin the rcs portion of cvs associates the checkin comment with
a version number! no need to do anything special there. 

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

you might pre parse with cvs2cl.pl 

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

-- 
______________________________________________________________________________
I'd crawl over an acre of 'Visual This++' and 'Integrated Development
That' to get to gcc, Emacs, and gdb.  Thank you.
        -- Vance Petree, Virginia Power

The opinions expressed here are not sanctioned by and do not necessarily 
represent those of my employer.