This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: cygwin's cvs


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]