Re: Bug tracking.

[Todd Denniston]

J wrote:
> 
> > Well, I think you haven't tested what you are saying.  Indeed, there is
> I've explain it poorly prehaps.
> 
> > So you can gladly go without tags: you just need to have in place an
> > alternate method to know that bugfix X is composed by foo.c at revision
> > 1.2, bar.h at rev. 1.27 and whee.dat at rev. 1.1.1.1
> 
> Yes, but what I would like is a uniqe commit number, whatever it may be, 578
> for instance applied to all the files involved in that single commit.
> 
> I commit my changes and cvs says:
> Commited change #578
> 
> ... Then I could say in my bug log:
> 
> Fixed memory leak, in commit #587
> 
> Then, it would be nice if you could go
> 
> cvs diff -r #587 -r #586
> 
> and it would say:
> 
> changed files:
> 
> main.c
> ...diff
> 
> fish.c
> ...diff
> 
> other.c
> ...diff
> 
> Still I guess I could just say:
> 
> "Fixed memory leak, in version main.c 1.2, fish.c bar.h 1.27  other.c
> 1.1.1.1"
> But it would be difficult to get the right versions out.
> 
> With a commit number you could go:
> cvs update -r#586
> 
> The answer it to use labels I guess, but I don't really want to label all
> the files just for a minor bug fix.
> 
> I just thought it would be a useful feature to be able to go back to state
> just after a specified commit. You could see exactly what's been done at any
> point, without having to label everything first. (this numbering thing is
> ofcourse is an implicit labeling system at commit time)
> 
Actually CVS does 'sort of' apply an implicit label at commit time.  It time
stamps the checkin, use '-D' to get it back.  One caveat, this might get
mangled if someone else was doing a checkin at the same time or same second. 
And I have found just putting a BUG_ID field in the commit comments (you can
enforce this with a rcsinfo script) to be adequate to track when changes went
in and what they changed, though I use 
http://search.cpan.org/author/FLUFFY/CVSUtils-1.00/ or
http://www.red-bean.com/cvs2cl/ to generate my bug fix log. And why is it you
don't want to apply tags, like just after doing the commit to fix 586 to just
issue `cvs tag fix_586` either in the same directory or at the base of your
sand box?  It has been a while since we discussed on the list as to whether
many tags slowed things down, but IIRC it seemed that it was not a problem
until you had several hundreds of files with several thousands of tags.

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