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.
