Re: source code for rcs57nt / cvs-1.9-win?

[Donald Sharp]

On Tue, Sep 26, 2000 at 02:50:24PM -0700, Gregory L Priem wrote:
> On Tue, 26 Sep 2000 14:16:14 -0700, Donald Sharp wrote:
> 
> >Why don't you just fix vss2rcs.js to check the date returned by vss
> >and if it's greater than what could even remotely be possible change
> >it to a sane value?  Seems like a lot of work to hack cvs when you
> >should just hack the input script...
> 
> I probably should have mentioned that that was what i originally
> tried, but it got more complicated, since this is not just restricted
> to the year being goofy. [the 2020 stuff is not really difficult to
> take care of, as most of them were 'really' 1998. There are also some
> dates of 2000 (probably doing y2k testing and forgetting to turn the
> date back), which are not as easy to identify as being 'bad']
> 
> The complication can perhaps been seen in a multiple developer
> environment with the developers in multiple time zones, since VSS does
> not have any time-normalizing or control. 
> 
> Here is one sequence which is in our vss:
> 
> 1. Developer A checks in source, 5pm his time, and then leaves for
> home. 
> 2. Developer B [in time zone 1 hour behind developer A] finds bug in
> source, fixes it and checks it in, 4:30pm his time. 
> 
> catching and trying to fix all of them up would be a nightmare. much
> quicker, but less desirable, would be to use the current date/time
> when checking in the files, but then the full span of time would be
> lost in the conversion [oh - i fixed that bug while you were on
> sabbatical last year]
> 
> with the rcs 5.7 ci.c source, it seems like it does a simple check for
> date, sends a message, and does a 'continue'. a simple commenting out
> of the continue may be a usable kludge. 

This will break other cvs commands.  Lots of cvs commands depend on the date
time stamp increasing from oldest->newest.  With this kludge you'll
be able to get the information in.  But you will not be
able to get the information out in a meaningfull manner.  Suppose

I have a file with these version- timestamps:

1.1 - 09-01-2000
1.2 - 08-01-2000
1.3 - 09-03-2000
1.4 - 09-04-2000

Now suppose I do a diff of this file versus the contents of the file
on 09-01-2000.  CVS now would only diff versus the 1.2 version of the
file versus the correct version that would be 1.1.  This is just one
example of where cvs would fail.

It's better to not be able to ask these questions instead of asking
these questions and just getting *wrong* information.  The more I think
about it.  If you can't guarantee the correct time as you import than 
you shouldn't import the time stamps( just say it's lost ).

donald

> 
> i figured, since rcs appears to be gpl, that source _should_ have been
> available at some point and someone might have it. 
> 
> 
> 
> greg priem                         kb0erz
> address@hidden
> bark, fido, bark [neither of us speak for my employer]