[Top][All Lists]

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

RE: WinCVS incorrectly showing locally modified files

From: Chuck . Irvine
Subject: RE: WinCVS incorrectly showing locally modified files
Date: Fri, 9 Mar 2001 12:04:40 -0600


I've done some checking and I do believe we have the same problem. I'm 
sharing work areas between WinCVS and Cygwin (is that what you meant?). 
For most everything, I use the command line cvs from a bash shell. 
Every now and then, I pull up WinCVS, mostly to graph a file's revision 
tree. Anyway, I've verified that I have what seems like the same 
problem that you describe. When I do an update from the cvs command 
line using cygwin's cvs.exe, the day indicator in the date string is 
missing the leading "0" and the corresponding file gets marked as 
modified in WinCVS. If I then do an update from WinCVS, the file goes 
back to up-to-date status and the leading 0 appears in the date string.

I had never heard before that sharing the same workspace from both 
WinCVS and cygwin/cvs is not recommended. I guess, as you suggested, 
that I could use the WinCVS version of of cvs.exe from the bash command 

I wonder whether we should expect a patch anytime soon?



> -----Original Message-----
> From: dlmart2 [mailto:address@hidden
> Sent: Friday, March 09, 2001 1:40 AM
> To: Chuck.Irvine; info-cvs
> Cc: dlmart2
> Subject: Re: WinCVS incorrectly showing locally modified files
> > WinCVS version 1.2 is incorrectly reporting that cvs 
> controlled files 
> > are locally modified. Interesting it only does this for 
> some files and 
> > not others. To check out files, I'm using the version of 
> cvs.exe that 
> > comes with cygwin (version 1.11). Any help is greatly appreciated. 
> > Thanks
> > 
> Chuck,
> I just submitted WinCVS Bugzilla bug# 432 which may be the
> problem you're seeing.  I'm sharing working areas between
> Unix and WinCVS (yes, I know, I know, a bad thing).  I've seen the
> false modified file problem before, but I think I've just now isolated
> the condition under which it occurs.
> If a CVS working area is shared by both WinCVS and Unix (Solaris 2.6,
> CVS 1.11, pserver mode), an update by Unix produces a different
> date/time format than WinCVS in the CVS/Entries file for days of the
> month between 1-9.
> e.g.
> Unix: Fri Jan  5 18:09:51 2001
> WinCVS: Fri Jan 05 18:09:51 2001
> When you use cygwin cvs.exe for checkout, you might want to
> look at the Entries file to see if the timestamp contains the leading
> 0 or a padding space.  If it applies a padding space, then it's the
> same problem as I'm describing here.
> In WinCVS Common Gui CvsEntries.cpp, the method "unmodified"
> checks for equivalence between the Entries date/timestamp (ts)
> and the file's modification time (cp) and returns strcmp(cp, ts) == 0;
> where in this example case
> cp = Fri Jan 05 18:09:51 2001
> ts = Fri Jan  5 18:09:51 2001
> strcmp() returns non-zero, the return value is 0 (i.e. Modified), and
> this results in WinCVS showing a red icon and "Mod. File".
> The underlying culprit here, I believe, is in the C libraries.
> Unix/cygwin and Visual C++ are not adhering to the same output
> format for ctime() or something along those lines.  Can't blame the
> programmers for calling "standard" C library functions and expecting
> the same output!
> This could be fixed by copying the Entries file timestamp string (ts)
> to another string.  Then transform the copy's first character of the
> 2-character day field from ' ' to '0' prior to comparing it with cp.
> I'm afraid this does require a patch to WinCVS.
> Or, you could try the cvs.exe that comes with WinCVS for
> your command line operations instead of the cygwin version.
> As a workaround, you can simply do a recursive cvs status
> or update from the top-level directory of your working area
> using WinCVS.  This regenerates the Entries file in the
> timestamp format expected by WinCVS.  
> David Martin
> _______________________________________________
> Info-cvs mailing list
> address@hidden

reply via email to

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