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.
Received on 2012-11-08 00:36:54 CET