On Fri, Aug 06, 2010 at 02:28:11PM -0400, Bob Archer wrote:
> But really why do people want this. I think it is so some settings like auto-props and other things that need to be set for a specific project will take place without having to distribute a config or send an email with "make sure you add this to your config" type of warning from a pre-commit hook that notices certain properties are missing for certain file types.
>
Auto-props are one killer app.
Another one is save-plaintext-passwords = no.
It's documented in trunk/notes/feedback/cmpilato-user-calls:
* Server-side control of client-side behaviors: Admins want to know
that every Subversion user has the same configuration for simple
things like auto-props rules, and want to be able to control
things like our "store-plaintext-passwords" toggles remotely in a
way that's not easily override-able.
Looking at the current set of variables we have in ~/.subversion/config,
there are a few that set up Subversion to behave according to a user's
individual preference, and don't affect other users:
editor-cmd, diff-cmd, diff3-cmd, merge-tool-cmd, diff-extensions, ssh,
no-unlock, interactive-conflicts
But we also have these which should probably be configured similar
for all users working on the same project anyway:
global-ignores, log-encoding, use-commit-times, mime-types-file,
preserved-conflict-file-exts, enable-auto-props
I haven't looked at the 'servers' file.
I'm not against adding a repository-configuration feature if we really
need it. But before thinking about implementation details of this feature,
such as how one type of configuration setting can override another, we
should clearly define the use cases that require repository-dictated
configuration. And ask ourselves and our users whether repository-dictated
configuration is really the best way of solving these problem. And try to
come up with alternative ways of solving them. Why do we have settings
in the individual client config that all users would want to share anyway?
For instance, regarding auto-props I'm not really sure I understand why
users have to set them in the config in the first place. It makes this
feature quite inconvenient to use in my opinion. At least I've never
been bothered enough to enable it for every-day use. It would be much
nicer if Subversion simply set properties like svn:eol-style up according
to the project's convention, leaving me with the possibility to override
the default before commit.
So maybe having auto-props in the config is part of the problem? What about
having an svn:auto-props property at the parent directory, specifying
autoconf settings for its direct children?
Too inconvenient to set up due to lack of recursive property support?
Would 'svn propset -R' do to configure auto-props for an entire subtree
like '/trunk'? Once those properties were set up and configured, users
could mostly forget about auto-props unless the default auto-props need
to be changed. Not whenever they start working on a different client
computer, as they do today.
So maybe defining additional properties in the svn: namespace that allow
project-wide configuration of Subversion's behaviour would make sense.
svn:global-ignores, svn:log-encoding, svn:use-commit-times,
svn:mime-types-file, svn:preserved-conflict-file-exts, svn:auto-props
The only question left then is about how these properties would be scoped,
i.e. where do you set them and what do they affect.
The store-plaintext-passwords could also be addressed with a configuration
switch that turned off plaintext password storage at compile time. Then
you have to compile your own client to use the feature.
Or we just flip the default from 'ask' to 'no', and let users who really
want their passwords saved in plaintext take an extra step to enable the
behaviour. I think the current default behaviour (prompting) is good
middle-ground, but it's possible that in some environments administrators
really do not want users to have a choice in the matter by default.
Yet users who really want to be disobedient and save their passwords in
plaintext will always be able to do so somehow, no matter what we do.
We can't solve a social problem.
Depending on how admins manage user software, they might be able to install
a system-wide configuration file on their user's machines that tells all
Subversion clients to say 'no' by default.
This is done on OpenBSD when Subversion is installed from the OS-provided
binary package, for instance:
$ cat /etc/subversion/servers
# $OpenBSD: servers,v 1.1 2009/08/25 10:26:20 stsp Exp $
[global]
store-plaintext-passwords=no
$
Stefan
Received on 2010-08-06 21:52:29 CEST