subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johan Holmberg <>
Subject Re: Strange diffs after rsync copying of working copy
Date Fri, 03 Feb 2012 15:17:57 GMT
On 02/03/2012 03:22 PM, Philip Martin wrote:
> Johan Holmberg<>  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"):


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

View raw message