On 02/03/2012 03:22 PM, Philip Martin wrote:
> Johan Holmberg<holmberg_at_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
> 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"):
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
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?).
Received on 2012-02-03 16:18:37 CET