[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Strange diffs after rsync copying of working copy

From: Johan Holmberg <holmberg_at_iar.se>
Date: Fri, 03 Feb 2012 16:17:57 +0100

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
>> 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
Received on 2012-02-03 16:18:37 CET

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.