On Sat, 2010-08-07 at 07:58 -0400, Daniel Shahaf wrote: > Stefan Küng wrote on Sat, Aug 07, 2010 at 12:59:26 +0200: > > On 07.08.2010 12:44, Daniel Shahaf wrote: > >> If corporations want to have configuration override, fine. > >> > >> But I want a way to disable that completely. I don't necessarily want to > >> allow a random sourceforge repository to control my auto-props settings for > >> a wc of that repository. > > > > Maybe a stupid question: why not? > > Why don't I let ezmlm configure my mailer's "use html?" setting?
I think he was asking for an answer specifically relating to auto-props, not an answer about configuration in general. There's not generally a lot of room for individual disagreement about what auto-props should be for a given project. My thinking about repository configuration is that the uses cases should be divided into two categories: 1. Stuff that isn't really client configuration at all, like auto-props, should come from the repository instead, and should only come from client configuration for compatibility. 2. Stuff that is client configuration should only come from client configuration. Client control is not legitimate business for an open source product, though it could be the business of a proprietary value-added fork. Note that there's no general extension of the config framework here, no whitelisting or blacklisting, no override settings. Invent a mechanism for getting repository configuration from the server and apply it to the specific use cases in (1), falling back to client configuration as a legacy mechanism.
