[Top][All Lists]

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

RE: Since DST started, cvs update uploads entire sandbox, every time

From: Arthur Barrett
Subject: RE: Since DST started, cvs update uploads entire sandbox, every time
Date: Mon, 17 Mar 2008 01:06:56 +1100


This problem has been around forever (err - since windows NT to be more 

It was fixed (with much painstaking effort) in CVSNT years ago.  If you are 
after a working CVS client for windows the easiest solution is just to use 
CVSNT (works just as well on Linux of course), alternatively you can get the 
sources and work out what was changed, or ask the CVSNT newsgroup where Tony or 
someone may remember...


Arthur Barrett

-----Original Message-----
From:   address@hidden on behalf of Nelson Bolyard
Sent:   Sun 3/16/2008 11:59 AM
To:     address@hidden
Subject:        Since DST started, cvs update uploads entire sandbox, every time

Hi again,
I use the cvs-1-11-22 client on Windows XP SP2 with an NTFS file system.

Last November, when Daylight Savings Time ended for 2007 in the USA,
I found that every time I did a CVS update in any of the sandboxes
that had been checked out before DST ended, the ENTIRE sandbox got
uploaded to the server.  This happened every time.  Because of 
asymmetric data link speeds (many megabits/second down, less than
one megabit/second up), this took forever.  (30 minutes or more was
not uncommon.)  Eventually, at the suggestion of someone in this list,
I worked around it by checking out a whole new sandbox and abandoning 
the old sandboxes.  Not a happy solution, but CVS update in the newly
checked out sandboxes took mere seconds.  

Well, last Sunday, DST started in the USA for 2008, and the cvs update
problem immediately recurred, with a vengeance.  So, I decided the time
had come to dig into it.  I downloaded the cvs-1-11-22 sources, and 
modified them a bit to build with MSVC8 SP1 (the code was originally 
built with MSVC6).  I built it and started debugging.  

I found that when cvs update gets the modification time stamp from the 
file in the file system (via its STRANGE stat-like function that actually 
uses FindFirstFile to get the file modification time), and compares that to 
the time recorded in the CVS/Entries file, it finds they do not match, and 
are off by exactly one hour.  So it concludes the file has been touched, and
uploads the file so the server will find changes in it.  I gather that the 
file timestamp matched the Entries file timestamp before the DST change, 
but now is off by an hour.  I surmise that the function that returns file 
modification time stamps is altering them for DST, EVEN THOUGH those values 
are GMT (UTC) values, and hence should not change with DST changes.  

Microsoft documents that this is a problem in systems that use the FAT
file system, but not in the NTFS file system.  Oddly enough, Microsoft
documents that the FindFirstFile function (which cvs seems to use in 
place of stat to get the file modification time) is one of the functions
that makes the mistake of adjusting GMT times for DST, yet CVS uses that
function in an apparent attempt to avoid that very problem.  :-/

I suspect that this problem is somehow exacerbated by the recent changes 
to the dates on which DST starts and ends in the USA.  DST boundaries 
simply were not a problem on Windows XP before that.  I suspect that some
code thinks that the USA is now in DST, and other code thinks it's not.  
Also, some functions seem to pay attention to the TZ environment variable
and others do not.

One strange thing is that cvs update does not "correct" the modification 
time stamps in files whose timestamps seem wrong but whose contents are
unmodified, at the end of a successful update, so that the next update
will be happy.  Seems like it should do that.

I think this problem can be worked around by adding code that determines,
by experiment, whether Windows is fudging time stamps, in in which direction,
and then compensates for those functions that do.  My objective is to 
produce a build on cvs-1-11-xx that doesn't go haywire every time DST 
changes.  This problem is rather challenging to test, because it requires
having a sandbox that was checked out before the most recent DST boundary.
Fortunately I have some of those at hand.  

My questions are:
a) has anyone else already found another solution to this problem, one 
that obviates abandoning sandboxes twice a year on DST boundaries?
("Switch to Linux" doesn't count. :)
b) Is this problem perhaps fixed in cvs-1-12-xx?

If not, wish me luck.

Want an e-mail address like mine?
Get a free e-mail account today at!

reply via email to

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