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

[Mark O'Brien]

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.

> -----Original Message-----
> From: address@hidden [mailto:address@hidden Behalf Of
> Mike Castle
> Sent: Thursday, February 15, 2001 1:07 PM
> To: address@hidden
> Subject: Re: 2 "how to <> in CVS" questions
>
>
> 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.
>
> From reading your description of what you want to do, I was wondering
> something:
>
> How do you handle the situation where a particular bug fix may
> take several
> commits of the same file.  That is, multiple revision numbers to one bug
> fix.

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.

> I mean, the whole reason for having SCM is so that you can step
> back at any
> point of time.

** WARNING: MY VIEW OF SCM ***
That is a side effect of SCM. The concept behind CM is that everything has a
configuration and that configuration will change over time. In reguards to
software, SCM is there to manage, control and track change to the
configuration of software (not to have things in place to be able to go back
and find out what happened if need be, SCM is proactive, not reactive).
Basically, you define what changes you want (reqs. or bug fixes), you plan
for the change (design), implement the change (dvlp), and verify the change
(test). SCM manages and ensures changes to configurations are known and
controlled over the SDCL. A by-product of SCM is that you can go back and
modify changes previously (rework, remove, enhance. etc. the prev. changes)
made, because of the reason you have SCM in the first place.

>             So, it may be that a particular bug fix may require the
> developer to perhaps step down the wrong path at some point at part of an
> investigation, and therefore back out some changes.  So, without the
> ability to use the SCM, because it appears to be tied down to one
> version/bug fix, the developer is forced back to the old broken method of
> keeping their own backup copies of the files.  Almost as bad as having no
> SCM in the first place!

I think you read to much into my SCM process based on purely isolated
functional questions about the capabilities of the version control tool.

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

Cheers,

> mrc
> --
>        Mike Castle       Life is like a clock:  You can work constantly
>   address@hidden  and be right all the time, or not work at all
> www.netcom.com/~dalgoda/ and be right at least twice a day.  -- mrc
>     We are all of us living in the shadow of Manhattan.  -- Watchmen
>
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs