]On 3 October 2015 at 13:19, Stefan Sperling <s...@elego.de> wrote:
> On Sat, Oct 03, 2015 at 11:13:08AM +0200, Edward d'Auvergne wrote:
>> is it really not a bug when:
>>
>> enable-auto-props = yes
>>
>> and:
>>
>> enable-auto-props = no
>>
>> both enable auto-props?
>>
>> Cheers,
>>
>> Edward
>
> I think your best way forward is what Ryan suggested: Ensure svn:mime-type
> for *.xml is set to 'text/plain' by setting svn:autoprops at the root of
> your repository. Then, over time, as your users upgrade to 1.8 clients
> and beyond, this problem will fix itself.
>
> Note that setting mime-type to 'text/plain' will have the same effect
> as if a file which is a "text file" (as guessed by SVN based on
> implementation-defined heuristics) does not have a mime-type set.
>
> When I added the libmagic support (yes, I'm responsible) I had to ensure
> the existing auto-props mechanism kept working. So mime-type detection
> with libmagic happens *after* autoprops and only if autoprops don't set
> a mime-type. That's where this design decision came from.
>
> I'm sorry this implementation doesn't work out of the box for you,
> and if I had known about your situation I might have made different
> choices while implementing this feature years ago. Alas, it's water
> under the bridge now, and you're the first person to complain about
> this ever, and there are mulitple ways you can work around the problem.
>
> So please stop calling behaviour you don't agree with a "bug".
> Call it what it is, a particular behaviour, which might not fit
> every single use case out there.
>
> I hope this works out fine for you in the end, one way or another.
> I'm very happy to see SVN supporting an awesome project like yours!
Hi,
Maybe I should better explain the confusion from the perspective of
the Subversion user, and the current inability to use 'svn import'. I
have been poking around the code and test suite to work out what the
design is, as this is very unclear in the docs. I see two parts:
[auto-props] - User defined svn properties to be automatically
applied with 'svn add' or 'svn import', defined in the user or global
'config' file.
[magic-auto-props] - A fallback for svn:mime-type when
[auto-props] returns nothing. This uses libmagic to set a specific
svn property automatically. I use the [magic-auto-props] label as
this is clearly an automatic property.
Adding to the confusion is that that the libmagic automatic property
layer is described in the "Automatic Property Setting" section of the
svn manual:
http://svnbook.red-bean.com/en/1.8/svn.advanced.props.html
So the following setting disables [auto-props]:
enable-auto-props = no
If a svn:mime-type was defined in the config file, this is now
disabled. However in this case, [magic-auto-props] then decides to
tag everything with svn:mime-type. So the desired user action of
disabling automatic properties is replaced by the second layer of
magic that automatically adds a property, contrary to the direct
English translation of "enable-auto-props = no" -> "do not enable
automatic properties". Note how this design is incredibly confusing
from the user's perspective, when the desired action is to avoid
having svn:mime-type set.
This is clearly overcome with the new option:
enable-magic-file = no
However the svn documentation really needs to clarify this
double-layered automatic property setting and, to override it, that
you need to set both:
enable-auto-props = no
enable-magic-file = no
I would maybe suggest introducing an option for disabling the entire
automatic property subsystem, i.e. it combines both of these, and
overrides them. This is an interesting thought experiment - devise
any name for such a top level automatic property override - and this
should convincingly demonstrate the confusion that the current setting
names induces.
As for the situation for the FlightGear aircraft repository, the file
diversity is so insanely huge that we just cannot ever trust the 3rd
party - libmagic - in the future to not cause other text files to be
treated as binary in the svn repository. The inbuild svn client and
server detection of binary vs. text without svn properties is all that
is desired. This is rock stable and works perfectly 100% of the time.
I have not encountered a situation where a text file should be treated
as binary (i.e. large text files consisting of only 1 or 2 or a few
lines). I.e. only situation were the svn:mime-type property override
of the binary vs. text detection is useful (from the repository
backend and binary vs. text perspective). In most cases, the aircraft
developers will not register the missing diff as a svn property
problem and just commit with everything treated as binary. This was
what has happened historically in a number cases, and is why I have
written a pre-commit hook script to block all svn:mime-type
properties.
The problem with the svn:mime-type block is that for svn clients <
1.9, 'svn import' can never work. Specifically because the libmagic
layer overwrites any user decision to disable automatic properties.
The only solution I can see is to give these instructions in the
FlightGear documentation:
- To use the 'svn import' command, you must have version 1.9 or
higher of Subversion installed, and in your ~/.subversion/config file
set both the "enable-auto-props = no" and "enable-magic-file = no"
options.
- To avoid the automatic setting of svn properties with 'svn add'
and the blocking of commits due to the svn:mime-type property being
set, you must use version 1.9 or higher of Subversion, and in your
~/.subversion/config file set both the "enable-auto-props = no" and
"enable-magic-file = no" options.
I just hope that Linux distributions quickly transition to svn 1.9 clients.
Cheers,
Edward
