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 <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2010-08-10 20:25:13 CEST