Nelson/Mark, This problem has been around forever (err - since windows NT to be more accurate): http://www.codeproject.com/KB/datetime/dstbugs.aspx
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... Regards, Arthur Barrett -----Original Message----- From: [EMAIL PROTECTED] on behalf of Nelson Bolyard Sent: Sun 3/16/2008 11:59 AM To: [email protected] Cc: 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 www.mail.com!
