Re: last modified date in CVS

[Hans-Bernhard B. <br...@ph...>]

Daniel J Sebald wrote:
> Hans-Bernhard Broeker wrote:

>> On the other hand, any discussion of CVS versions older than 'today' 
>> is futile by definition.

> That I don't know about.  It's useful from the developers standpoint for 
> the case where a bug finds its way into CVS.  

Not necessarily.  The primary information needed is: is it *still* 
present in current CVS version?  If not, case closed --- somebody 
already fixed it in the meantime.

If a bug is found in current CVS, and you really need to know when it
got in there (e.g. because you can't figure out what causes it, so you 
need to home in on the change that introduced it), you'll have to run 
explicitly backdated checkouts anyway --- a time stamp in the executable 
doesn't add any new information then.  You know which date you just 
checked out.  But honestly, in all the years we have had a CVS source 
tree, I don't recall having done that more than maybe once or twice.

> Say you're a developer and recognize your copy of gnuplot is a couple
> weeks old by looking on the screen.  So, you update.  You find a bug
> and can report back to the list what day it was last working.

No, you can't --- you can only report when it was still working.  You 
don't know if the _last_ working version was three weeks or three hours 
ago, only that it's less than a couple weeks ago.  To really nail down 
the last working version, you still have to run a series of 'cvs update 
-D <date>' test builds.

Anyway: if you're running the CVS version, you're supposed to have a 
checked-out copy of the sources around, corresponding to the binary 
being used.  And even if you don't, you can still check the RCS $Id 
strings embedded in the binary ('ident gnuplot') to find out.

So to sum it up, the only thing really likely to be achieved by putting 
a CVS update time stamp into the banner printout is to encourage ab-use 
of the CVS version.