subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edward d'Auvergne" <>
Subject Re: Bug report: The auto-props setting of svn:mime-type is impossible to avoid.
Date Sat, 03 Oct 2015 08:48:14 GMT
On 3 October 2015 at 01:05, Greg Stein <> wrote:
> On Fri, Oct 02, 2015 at 10:06:26AM +0200, Edward d'Auvergne wrote:
>> As this bad behaviour can be so incredibly damaging for this
>> repository,
> Note: the files themselves are not "damaged" -- Subversion will never
> alter the contents of a file when it is first imported/added. It may
> make a file look different in the working copy, according to
> svn:eol-style. But the svn:mime-type is just a property associated
> with the file. Its only real use is when the file is served via HTTP
> to a web browser.

Hi Greg,

The damage is to the repository backend and to the development process
itself.  Treating text files as binary has a number of significant
consequences for development.  For example:

- 'svn up' can no longer perform merges (G).
- 'svn merge' or the script can no longer function to
merge changes to the same file.
- A one character change to a massive text file results in a diff and
db/revs backend file the size of the whole file, and not just a few
lines for a proper diff.
- Changes can no longer be reviewed (

This is a severe bug.  Here is an interesting sign as well:

$ svn propset svn:mime-type "application/xml" dash-set.xml
svn: warning: 'application/xml' is a binary mime-type but file
looks like text; diff, merge, blame, and other operations will stop
working on this file
property 'svn:mime-type' set on 'dash-set.xml'

Unfortunately 'svn add' and 'svn import' set this binary mime-type
without warning, and when explicitly told not to.

> If a file is committed to the repository with an svn:mime-type, why
> don't you just delete/correct the property in a following commit?

Does this answer your question ;)

[edward@localhost flightgear-fgaddon]$ svn info
Path: .
Working Copy Root Path: /flightgear/flightgear-fgaddon
URL: svn+ssh://
Relative URL: ^/trunk
Repository Root: svn+ssh://
Repository UUID: 9eb9bc84-db9d-4e05-893b-26dd41ac94a6
[edward@localhost flightgear-fgaddon]$ find -type f | grep -v .svn | wc -l
[edward@localhost flightgear-fgaddon]$ find -name "*.xml" | wc -l
[edward@localhost flightgear-fgaddon]$ find -name "*.ac" | wc -l
[edward@localhost flightgear-fgaddon]$ find -name "*.nas" | wc -l

Manually monitoring this huge beast is out of the question.



View raw message