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

Re: svn status/diff false positive

From: Ryan Schmidt <subversion-2014_at_ryandesign.com>
Date: Mon, 11 Aug 2014 23:12:58 -0500

On Aug 11, 2014, at 6:53 AM, Ivan Drobyshevskyi wrote:
> On Mon, Aug 11, 2014 at 11:05 AM, Ivan Drobyshevskyi wrote:
>> There's a strange behaviour that is reproduced for some files in our
>> subversion repository: `touch`ing this file(s) makes `svn diff` show
>> entire file as changed. Similar happens when opening-saving file in
>> any text editor or copying it back and forth.
>> touch:
>> $ svn status cmVectorStream.h
>> $ touch cmVectorStream.h
>> $ svn status cmVectorStream.h
>> M cmVectorStream.h
>> copy-restore:
>> $ svn status cmVectorStream.h
>> $ cp cmVectorStream.h cmVectorStream.h.bak
>> $ cp cmVectorStream.h.bak cmVectorStream.h
>> $ svn status cmVectorStream.h
>> M cmVectorStream.h
>> $ diff cmVectorStream.h.bak cmVectorStream.h
>> <empty>
>> For the vast majority of files in a repo the above doesn't happen, so
>> far I've only encountered two such files. Since svn shows entire file
>> as changed it might be related to line endings however I don't see how
>> touch'ing file could possibly trigger such behaviour.
>> I'm running Ubuntu 14.04.1, both stock subersion (1.8.8) and the one
>> compiled from source (1.8.9 with only --with-serf option set) expose
>> similar behaviour. The repository itself is hosted on Windows machine.
>> Should I fill in a bug report on this?

> Removing svn:eol-style (was set to 'native') for files in question
> property solved the issue. I guess it's some weird interaction between
> Tortoise SVN hosted repository and upstream subversion.

It is the responsibility of the Subversion client to normalize the line endings to LF if you have svn:eol-style set. The official client and libraries do this; perhaps you committed these files using a reimplementation that does not do that. git-svn comes to mind, for example. TortoiseSVN uses the official Subversion libraries and so should not be affected.

If the timestamp of the file and its pristine match, Subversion assumes the contents match as well. When you touch one, then it has to actually compare the contents, which is when it discovers this error.
Received on 2014-08-12 06:13:34 CEST

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.