On 08/07/2010 12:18 PM, Greg Hudson wrote: > 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.
Are you saying that client control isn't legitimate because of some fluffy open-source principle that checks that right at the door, or because of the practical impossibility due to the fact that the client source code is available for modification and recompilation? The foremost bit of client configuration that CollabNet's Subversion customers are demanding (besides auto-props, which I think we all agree on) is a way for the server to set a policy which dictates that clients may not use plaintext or other insecure password storage mechanisms. I claim it's ridiculous to propose that we need a custom fork of Subversion, Subclipse, TortoiseSVN, AnkhSVN, etc. -- all just to bang in this feature. What, then, do you propose? Do you use server-side configuration to demand, say, client certs (which you still can't guarantee are passphrase-protected, right?)? Do you rip insecure password storage out of Subversion altogether? -- C. Michael Pilato <cmpil...@collab.net> CollabNet <> www.collab.net <> Distributed Development On Demand
signature.asc
Description: OpenPGP digital signature
