Re: last modified date in CVS

[Daniel J S. <dan...@ie...>]

Hans-Bernhard Broeker wrote:
> Harald Harders wrote:
> 
>> On Tue, 22 Nov 2005, Hans-Bernhard Broeker wrote:
> 
> 
>>> Please keep in mind that not all developers are on Unix ...
> 
> 
>> Oh yes, I sometimes forget this. How do these people work?
> 
> 
> With difficulties, needing tools that emulate a Unix environment 
> (Cygwin, DJGPP).  I've been in that position myself for quite a while
> now --- the machine I spend my days sitting in front of runs Win98.
> 
> And there's another gotcha of a client-side approach: not everybody runs 
> 'prepare' all the time.  On Linux, if your tools are recent, you 
> generally can rely on a simple 'make' to get it all right by itself.
> 
>> This sounds good. The big advantage of being able to find out of which
>> date a CVS version is, is comparability.
> 
> 
> On the other hand, any discussion of CVS versions older than 'today' is 
> futile by definition.
>  So we don't need a date stamp on the screen --- 
> we only need to know that the binary is built from current sources. 
> People who can't be bothered to cvs update and re-build before reporting 
> a problem, shouldn't be building from CVS in the first place.


That I don't know about.  It's useful from the developers standpoint for the case where a bug finds its way into CVS.  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.

It may also be useful for referencing against the ChangeLog.

For maintenance personel at universities and labs who might be used to working with bleeding edge releases, that date may be a reminder that gnuplot is long out of date.

Removing the date would still be better, I think, than showing the code was last modified two years ago when it actually was modified two days ago.

Dan