On 02/03/2012 03:22 PM, Philip Martin wrote:
Johan Holmberg<holmb...@iar.se> writes:
On 02/03/2012 02:50 PM, Philip Martin wrote:
I have now done some further experiments. I just issued commands like this:
$ svn status # no modified files reported
Subversion is not doing a full text comparison because the timestamps
match. So the difference that is present is not reported.
But this occurs right after a fresh "svn checkout". There can be no
differences.
If a fresh checkout really produces a working file with the wrong
contents then that is a checkout bug, but it is nothing to do with
status. What sort of difference is present? Is it something to so with
svn:keywords or svn:eol-style?
Yes, in one case I get a difference for the $Id$ line (from "svn diff"):
-$Id:$
+$Id$
and in the other files the "svn diff" show a difference on line endings
(Windows .vs. UNIX). But the files have svn:eol-style native set, and
appear as normal UNIX text files in the working copies.
To be really sure, I saved the file before/after my "touch + svn
status". The working copy file is identical before and after. But
first it is reported as unmodified and then as modified.
That doesn't prove anything. The file is reported as unmodified because
the timestamps match. That does not mean that the file is unmodified.
It means that the timestamps match. The file could have modifications
at that stage. When the timestamps differ that modification becomes
visible.
OK, I understand. So it appears to be a checkout bug instead (or some
other svn-internal problem with the ".svn" information in the directory?).
/Johan Holmberg