subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Subversion Wiki] Update of "ServerDictatedConfiguration" by CMichaelPilato
Date Wed, 14 Dec 2011 19:05:07 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Subversion Wiki" for change notification.

The "ServerDictatedConfiguration" page has been changed by CMichaelPilato:
http://wiki.apache.org/subversion/ServerDictatedConfiguration?action=diff&rev1=15&rev2=16

Comment:
Try to clarify some stuff that didn't quite jive on my last read-thru.

  == Design: Server-Dictated Configuration ==
- Many software development shops of non-trivial size desire to have (and to the extent possible,
to enforce) a uniform configuration environment among the various clients which commit to
their repositories.  Although these shops may have the ability to control the environment
on the client machines (dictating software versions, etc), relying upon the client for setting
various configuration parameters can be time-consuming and problematic.
+ Many software development shops of non-trivial size desire to have (and to the extent possible,
to enforce) a uniform configuration environment among the various clients which commit to
their repositories.  Although these shops may have some ability to control the environment
on the client machines (dictating software versions, etc), expecting humans to consistently
set and maintain various runtime configuration parameters in accordance with corporate policy
and on every repository-accessing client computer is both error-prone and unscalable.
  
- Subversion already provides the means of enforcing much (but not all) of this configuration
through the hook script mechanism.  What our users desire is some way of having the server
dictate a default or recommended configuration to clients.  The parameters of interest typically
come from the standard client-side config: things like global-excludes or auto-props.  Allowing
the administrator to store a default config on the server, which then gets pushed to the clients,
would save both time and frustration.
+ Subversion already provides the means of enforcing much (but not all) of this configuration
through the hook script mechanism, but at best this can only punish non-compliant client behavior
and clumsily recommend configuration changes (which, again, a human must implement on their
client computer).  However, allowing the administrator to store a default configuration on
the server, which gets automatically pushed to and honored by the clients, would save both
time and frustration.
  
  === Behavioral specification ===
- The high-level behavior for repository-dictated configuration is relatively simple: the
repository maintains a list of configuration parameters and values, and upon request, provides
these to the client who then applies them appropriately.
+ The high-level behavior for server-dictated configuration is relatively simple:  the repository
maintains a list of configuration parameters and values which, as necessary, the server provides
to the client.  The client, then, behaves in accordance with the server-dictated configuration.
  
  There are a number of specific bits of configuration that existing Subversion users and
administrators wish to have propagated from the server to the client.  There are also different
scopes at which administrators might reasonably wish to apply differing defaults for these
things:  server-wide, repository-wide, or local to a particular directory hierarchy within
a specific repository.  The following is a listing of those that we know about, with some
notes about scope and desired degrees of control:
  ||'''Configuration''' ||'''Scope''' ||'''Enforceability''' ||'''Notes''' ||
@@ -14, +14 @@

  ||ignores ||per-directory ||Enforceable via hook scripts ||Client should be allowed to override
this ||
  ||use-commit-times ||per-directory ||Unenforceable ||Client should be allowed to override
this ||
  ||log message templates ||per-directory ||Enforceable via hook scripts ||Doesn't fit the
name=value configuration motif quite as readily as some of the others.  Would a client need
to override this? ||
- ||myriad authn-related stuff ||per-server, per-repos ||Unenforceable ||Lack of enforceability
plus relationship to security means that admins do not want the client to be able to trivially
override this setting.  Precise requirements TBD (is this a boolean "allow/disallow plaintext
password caching", or "require X, Y or Z encrypted password stores", or ...?) ||
+ ||myriad authn-related stuff ||per-server ||Unenforceable ||Lack of enforceability plus
relationship to security means that admins do not want the client to be able to trivially
override this setting.  Precise requirements TBD (is this a boolean "allow/disallow plaintext
password caching", or "require X, Y or Z encrypted password stores", or ...?) ||
  
  
  
@@ -24, +24 @@

  }}}
  At least one user specifically called out the need for the server to enforce adherence to
the configured behaviors ''without'' requiring hook scripts to do so.  For example, if the
repository has a configured auto-props list, the Subversion C code is perfectly capable of
validating that incoming committed items obey those settings, failing the commit otherwise.
 This seems like a reasonable request so long as we permit admins to specify which of their
configuration settings are "suggested" versus "required" (again, taking into account that
anything unenforceable can't truly be "required").
  
- Subversion should recognize multiple levels of possible hierarchy in the server-side configuration:
+ Subversion could recognize multiple levels of possible hierarchy in the server-side configuration:
  
   1. server - Settings apply for all repositories and paths therein on the server
-  1. repository - Settings apply for all interactions with the repository and the paths within
it
   1. subtree within repository - Settings apply for paths at or under a given path in the
repository
  
  And at each level, multiple degrees of insistence in the actual configuration items:

Mime
View raw message