[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug tracking.

From: Todd Denniston
Subject: Re: Bug tracking.
Date: Mon, 09 Dec 2002 10:07:12 -0500

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]