On Jun 26, 2007, at 09:37, Jan-H. Jagla wrote:
> Andy Levy wrote:
>
>> On 6/26/07, Jan-H. Jagla wrote:
>>
>>> Ryan, thanks for the reply
>>>
>>> >> I'd like to be able to use
>>> >>
>>> >> * = svn:eol-style=native
>>> >>
>>> >> in the config file since we have about 500 file types in our
>>> repository.
>>> >
>>> > Hopefully none of your file types are binary, because
>>> > svn:eol-style=native will be applied to them as well, which
>>> will likely
>>> > corrupt them irreversibly.
>>>
>>> AFAIK, svn doesn't apply the svn:eol-tyle property to binary
>>> files but
>>> rather returns an error message, so that's fine.
>>
>> But what if you come across a new binary type which isn't known to be
>> binary before attempting to apply that property?
Subversion does happily apply svn:eol-style to binary files if you've
instructed it to, which you have. People often post to this list
>>> >> However, I would like to specify some file types which get
>>> special
>>> >> properties, e.g. *.pdf = svn:mime-type=application/pdf
>>> >>
>>> >> Is this possible and in which order do I have to arrange the
>>> entries
>>> >> in the config files?
>>> >
>>> > Good question. Maybe you can unset the svn:eol-style then too.
>>> I don't
>>> > know if it's possible or what order to do it in. You could
>>> experiment
>>> > and report back to us...
>>>
>>> The subversion book says:
>>>
>>> "Multiple matches on a file will result in multiple propsets for
>>> that
>>> file; however, there is no guarantee that auto-props will be
>>> applied in
>>> the order in which they are listed in the config file, so you
>>> can't have
>>> one rule "override" another."
>>>
>>> that's why I would like to know if anyone has experience with
>>> multiple
>>> matches and whats the best order?
>>
>> Per the section of the manual you quoted, the order doesn't matter.
>> There's no guarantee that it'll be followed, so there's really no
>> point in paying attention to it.
>
> thanks for your reply. Doesn't this then mean that I have to
> specify each of the 500 file types we use manually and every time a
> new type is added to the repo I will have to change all client
> configs?
Yes, that's what it means. You can install a pre-commit hook that
verifies that commits follow whatever your current practices are, and
if not, informs the user what they need to do, how they need to
reconfigure their config files, or even where they can download a pre-
configured config file.
> What if there are file types that could be binary but aren't always?
Sounds broken-by-design to me, of whoever made a filetype that could
be either. But presumably you now have this situation and have to
deal with it. There was a previous discussion on this topic on the list:
http://svn.haxx.se/users/archive-2007-05/0846.shtml
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jun 29 23:48:12 2007