You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2012/11/08 00:36:16 UTC
Inheritable svn:auto-props and the enable-auto-props config [was: disregarding svn:global-ignores]
Paul Burba wrote:
> As best I can tell we all agree now that a user should be able to
> disregard the svn:auto-props with --no-auto-props option. Having
> digested everyone's arguments on that topic I'm fine with that now.
>
> However I strongly believe that the default behavior of svn:auto-props
> should not be tied the config:miscellany:enable-auto-props runtime
> setting.
+1, but for this reason alone: We don't want new users to have to tweak their config before these auto-props will take effect. (The setting defaults to off, which was fine for its original purpose because you had to edit the config anyway to use auto-props so having to change this setting at the same time was no big deal.)
I think your argument here ...
> Doing so makes it too easy for users to permanently (and
> perhaps accidentally) disregard svn:auto-props. We want to give users
> to opportunity to override the repository recommended auto-props (as
> manifested in the svn:auto-props property) on an exception basis, but
> do we want to make it easy for users to simply "turn off" the repos
> recommended auto-props? Personally I think not. I assume a
> repository administrator who sets an svn:auto-props property on the
> root of their repos considers these autoprops the recommended default,
> only to be overridden in special circumstances, not something that can
> simply be switched off permanently by disinterested users.
... is too hung up on the notion that this is a repos-dictated config. It's not. The feature you have created is a per-subtree, user-controlled config. I bet the only auto-props that get set in our repo[1] will not be at the
root but at the "^/subversion/" level or deeper, and I bet they will
only be done by us for our own convenience, not demanded by any repository administrator.
I'm not saying users need an on/off switch for in-tree auto-props, but the idea of giving them one is not conceptually different from giving them the existing switch for config-file auto-props. If the project rules require certain props to be set, then the project members have until now been socially required to ensure that either their auto-props are enabled or they remember to set the required props in some other way. That same obligation will exist with the in-tree auto-props. If a user -- or a build-slave machine -- wants to globally turn off auto-props, let him/her/it do so.
So we do not need to be afraid of letting the user have such a switch, if someone were to come to us with a good reason for adding one. The important thing, rather, is to make it easy to do the common things -- comply with in-tree auto-props -- and that is why I agree the existing switch (because it defaults to off for new users) should not control it.
- Julian
[1] Not that
everybody's situations are like ours, of course, but many are.