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=8&rev2=9

Comment:
Attempt to record the most commonly requested server-dictated config bits and 
some notes about them.

  
  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.
  
- === Goals ===
- 
  === 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.
  
- It should be noted that the configuration the server dictates is only a 
*suggestion* to the client.  Clients may choose to override the suggestion with 
a configuration of their own, so appropriate server-side enforcement (often via 
hook scripts) is still recommended.
+ 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''' 
||
+ || auto-props || per-directory || Enforceable via hook scripts || Clients 
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 || Un-enforceable || 
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 ...?  ||
+ 
+ NOTE: The configuration the server dictates can at best be only a suggestion 
to the client, with well-behaving clients honoring that suggestion.  As free 
software, though, most such clients could be modified by a malicious user to 
ignore server-side suggestions.  Server-side enforcement of desired behaviors 
(where possible, and often via hook scripts) is still recommended.
  
  === Server-client transmission mechanism ===
  
@@ -20, +25 @@

  
  === Server-side storage ===
  
- ''TODO''
+ ''[TODO]''
  
  === Client-side storage ===
  

Reply via email to