Re: WinCVS incorrectly showing locally modified files

[David L. Martin]

> 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