Re: svn:auto-props on project root (was Re: svn commit: r1617096 - in /subversion/branches/svn-auth-x509/subversion: include/svn_x509.h libsvn_subr/x509.h libsvn_subr/x509info.c libsvn_subr/x509parse.c tests/libsvn_subr/x509-test.c)

Branko Čibej wrote:
>>> May be it's already discussed, but do someone have objections on
>>> settings 'svn:auto-props' on project root with content like this:
>>> [[[
>>>   svn:auto-props
>>>     *.py = svn:eol-style=native
>>>     *.c = svn:eol-style=native
>>>     *.h = svn:eol-style=native
>>> ]]]
>>>
>>> Sounds good to me. +1.
>>>
>>> There are a number of other patterns we want to add to that list: *.hpp,
>>> *.cpp, *.py, *.rb, *.pl, *.txt, README, BRANCH-README, etc. ad nauseam. I
>>> don't expect to find all of them on the first try, but we can sure try. :)
>>>
>> Done in r1621946. Thanks for your feedback.
>
> We'll need the same on ^/subversion/branches, too, since we do add new
> files on branches.

I mildly disagree. All new branches will get it automatically, existing dev branches will get it next time they get a catch-up merge, and existing release branches hardly need it because they generally receive only merges from trunk (and we could merge this to them if we want to).

> And I wonder if it wouldn't be better to just add the
> property on ^/subversion and maintain it in one place.

That's possible but feels like an unnecessarily out-of-band location. If a dev branch adds new files of some new extension, then that dev branch is also the place where the auto-props setting should be extended, so that the new setting gets into trunk only if and when the dev branch is merged to trunk. In this example it doesn't seem so good if the branch developer also has to make these adjustments to a separate location (that's not part of the branch checkout).

- Julian
Received on 2014-09-02 12:51:12 CEST