Lapo Luchini wrote: > I added Cc to Charles Wilson, CygWin's CVS package mantainer, sorry if > I quote everything, but it's for him getting a sense out of the message ^_^ > > Introduction: I filed a bug on TortoiceCVS "feature reqeust" tracker to > improve support of cygwin's CVS bty TortoiseCVS (that IMHO is the best > CVS front-end around), they told me that cygwin's cvs has some problems > about daylight saving time (that are indeed bug of windows itself, it > seems) > >https://sourceforge.net/tracker/index.php?func=detail&aid=551482&group_id=48103&atid=451975 >
The above is a bad link. Browsing thru the buglist for tortoisecvs, I find: [ 556160 ] timezone problem FAT vs NTFS http://sourceforge.net/tracker/index.php?func=detail&aid=556160&group_id=48103&atid=451972 which is blamed on CVSNT, not windows itself. Do you have a specific example using cygwin's cvs via the command line, where Daylight Savings Time causes a timestamp problem? >>>> [lapo] But cygwin's mantainers are not usually that conservative, >>>> they welcome patches... if you already have a patch to solve that >>>> problem could you please send it to cygwin's CVS mantainer? Yes I AM conservative when it comes to cvs. It would be very bad if it got broken, as that would halt every developer who hacks on cygwin1.dll or other cygwin packages from within a cygwin environment. (Folks who develop using a cross-build environment for cygwin on linux would be "safe", but) Worse, bad check-ins could seriously scrog the cygwin, gcc, binutils, and cgywin-apps repositories on sources.redhat.com. I am considering an update to cvs-1.11.2 in the (relatively) near future -- but that package will have about a two month shakedown period as a 'test' package before it gets made current... >>> [torsten] No, we do not maintain CVS. We just use the CVSNT port. >>> >> >> [francis] Well, the biggest thing the cygwin CVS maintainer could do >> is to >> actually ship CVSNT. CVSNT has been backported to Unix, and many people >> use it as a server under Unix. This port would be fiddly, as they would >> want to use the Unix port of CVSNT with cygwins compatibility layer, but >> still maintain features like the timestamp stuff on different filing >> systems. Euch. >> >> I guess cygwin could "fix" their stat function under Windows to look at >> the filesystem type, like CVSNT does. This could cause all sorts of >> weird consequences in other programs though. I still don't see a description of WHAT is wrong. "maintain features like the timestamp stuff". "fix the stat function to look at the filesystem type". ***what is broken???*** cygwin-cvs works fine for me and hundreds of others... From CVSNT Changelog: 31/10/01: Added equivalent DST fix for utime function (fixes edit/unedit). Removed WinCVS 1.2 DLL. 22/05/01: Merge in the latest version of stat() fixes by jmg. This should cover about 99% of cases now. An equivalent fix will (hopefully) be in the next version of WinCVS 26/03/01: Lots of DST fun... This is not a bug in cvsnt, nor is it as I initially thought a bug in WinCVS (although it handles it in a different way). It's an NT4/Win2k bug (test: Create a file, write down the time it was created, change your calendar to December. Check the time on the file. Surprised? so was I...). The quick workaround is to do 'cvs status -q' from the root of your sandbox which will touch all the files again. From http://www.devguy.com/fp/cfgmgmt/cvs/#DST ------------- 3) Why does this problem exist? Because Microsoft's Win32 API file status reporting functions report incorrect file modification dates. According to Microsoft, "This is by design." Thus, file status functions that work properly under Unix return incorrect results under Windows. Moreover, the incorrect results are incorrect in different ways depending on whether the file system is FAT or NTFS. WinCVS and cvsnt correct for this problem on FAT file systems, but the original authors did not correctly allow for the differences under NTFS. Microsoft's faulty documentation is more to blame than the hardworking authors of WinCvs and cvsnt. --------------- Now, it becomes more clear...there have been several instances where the time computation functions in cygwin -- which are in the times.cc and localtime.cc files -- were modified to compensate for these sorts of problems. cygwin's stat() function for disk files (in fhandler_disk_file.cc) uses cygwin's own time routines to convert the time values as returned by the windows routines into the the time values that go into the stat structure. As it happens, the function used to do this is to_time_t, which converts the windows-time (# of 100 nanoseconds since Jan 1 1601) to the unix time (# of seconds since Jan 1 1970). My point: cygwin itself seems to handle timestamps properly now. Whatever needs fixin' was fixed long ago, AFAICT. In fact, if you do the test mentioned above (26/03/01: ...) from within a bash shell, and use 'ls -l --full-time' you do NOT see the "jumping timestamp" problem. You do see it if you follow that procedure from a cmd.exe prompt, and use 'dir' to list the files. So, AGAIN I say, **what is the problem**? Do you have a testcase demonstrating a problem using cygwin's cvs client via the command line? Or have you only seen this bug when using TortoiseCVS -- which doesn't like cygwin-cvs anyway? >> In short, I don't have a patch which is in a form that th cygwin CVS >> maintainer could use. Somebody would have to sit down and thinkin about >> these issues to make one. Can such a patch apply to main CVS? Is it >> worth doing that, rather than using CVSNT? If changing to CVSNT what >> other issues are there? >> I have no intention of switching over to CVSNT. As far as I am concernedc, that is a totally different package. So far, you haven't even presented me with evidence that there's anything wrong with the current cygwin cvs.exe's handling of timestamps. > I've seen CVSNT has 6Mb of diff from CVS... quite hard to extract only > that part... > >>>>> [torsten] Do you have any special reason to prefer Cygwin's cvs.exe >>>>> for the CVSNT one? >>>>> >>>>> >>>> >>>> [lapo] Just that I use cygwin to develop and I compile from cygwin >>>> the programs I store in my CVS repository (or on sourceforge)... >>>> mixing CVSs gives strange permission on files and mixed EOL (13-10 >>>> versus 10)... [rest snipped] Lapo, you wondered why I had not responded to this message. It's because it was totally unclear as to WHAT the problem was. It wasn't clear whether you were actually reporting a bug with cgywin's cvs or just letting me know that TortoiseCVS doesn't work well with cygwin cvs (and that's my problem because???). Or maybe you were slyly advocating that I drop "regular" cvs and use cvsnt. I dunno. I couldn't tell -- and I've got better things to do that try to figure it out. Give me a test case with MY cvs. Tell me what is wrong and what should be fixed. Better, give me a patch. But don't expect me to respond to a cc: of a tangential discussion that only vaguely involves my cvs package. I DO read every message that concerns cvs. I don't always respond -- sometimes because the message makes no sense (like yours - sorry, but it's the truth) and sometimes just because I don't have time to deal with the issue. But they all get filed in the cygwin-cvs/ folder, and I always review them before making a new release. ('course, it's been so long since I made a new release of cvs, that the cygwin-cvs/ folder has a pretty huge stack of messages in it...) --Chuck -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
