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

[Chuck . Irvine]

Mark,

Attached are patches to CVS 1.11 that cause additional information to 
be passed to your commitinfo script, namely the branch being checked 
into. If you are interested, patch, do a build, and search the newly 
generated cvs*.info files for "AlternateInfo" for details on how to use 
this additional functionality. We use it for implementing branch 
locking. I've also attached our commitinfo script that we use for this 
purpose. Cheers!

Chuck

> -----Original Message-----
> From: mark.obrien [mailto:address@hidden
> Sent: Friday, February 16, 2001 12:51 PM
> To: David.Thornley; info-cvs
> Subject: RE: 2 "how to <> in CVS" questions
> 
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 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.
> 
> I have built build systems like this and have addressed the things you
> raised at the end of your mail. All the peripheral stuff I 
> can handle, its
> the 3 things above that I an having trouble with.
> 
> Thanks for your time and response.
> 
> Mark
> 
> > -----Original Message-----
> > From: address@hidden 
> [mailto:address@hidden Behalf Of
> > David H. Thornley
> > Sent: Friday, February 16, 2001 11:41 AM
> > To: address@hidden
> > Subject: Re: 2 "how to <> in CVS" questions
> >
> >
> >
> >
> > 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
> > http://www.visi.com/~thornley/david/
> >
> > _______________________________________________
> > Info-cvs mailing list
> > address@hidden
> > http://mail.gnu.org/mailman/listinfo/info-cvs
> 
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs
>

alternateinfo.patch
Description: Binary data

hped-deny
Description: Binary data