subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <comm...@subversion.apache.org>
Subject [Subversion Wiki] Update of "ServerDictatedConfiguration" by pburba
Date Wed, 04 Jan 2012 14:38:40 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 pburba:
http://wiki.apache.org/subversion/ServerDictatedConfiguration?action=diff&rev1=32&rev2=33

Comment:
Clarify the precedence of the configuration heirarchy.

  Over ra-neon/ra-serf, the client will receive the repository's configuration checksum as
part of the OPTIONS response.  It will request new configuration bits via a custom REPORT
request aimed at the repos-global report target (the "me resource" for HTTPv2, the "default
VCC" otherwise).  ra-svn will behave similarly, using the initial handshake/feature negotiation
phase for the repository's checksum delivery, and a new query for the configuration fetch.
  
  We'll need a way for clients to announce to the server that they will honor the server's
dictated configuration.  The obvious way is via a new capability, so administrators may choose
to use the presence/absence of the capabilitiy in the  list of capabilities passed to the
start-commit hook to determine  whether to allow commits from certain clients.  There are
a few different ways we might want to procede however:
- ||<tablewidth="793px" tableheight="176px" tablestyle="">'''Capability/Capabilities'''
||'''Notes''' ||
+ ||<tablewidth="793px" tableheight="176px">'''Capability/Capabilities''' ||'''Notes'''
||
  ||A single new capability string ("server-config") ||Simple, but isn't sufficient to differentiate
from later releases which might support new configuration options. ||
  ||New capability strings per supported option (e.g. "server-config-autoprops", "server-config-ignores",
"server-config-store-plaintext-passwords") ||Solves the problem at hand neatly, allows future
releases to add new configuration options, but while we're thinking about this space, haven't
you ever wished for... ||
  ||New capability for each minor release (e.g. "client-version-1.8") ||...A way for the client
to communicate it's version to the server?  This goes beyond what is needed for server dictated
configuration, but why not put it in place now? ||
@@ -129, +129 @@

  $
  }}}
  ==== Configuration hierarchy ====
+ As detailed in the behavioral specification matrix, only specific options will be made available
for server-dictated configuration. Server-dictated configuration will be the highest priority
configuration recognized by well-behaved Subversion clients. So the new order order in which
specific configuration options will be honored is as follows (lower-numbered         locations
take precedence over higher-numbered locations):
- As detailed in the behavioral specification matrix, only specific options will be made available
for server-dictated configuration. Server-dictated configuration will be the highest priority
configuration recognized by well-behaved Subversion clients.
- 
- So, the order in which specific configuration options will be honored where found is:
  
   1. Server-dictated configuration
+  1. Command-line options
   1. Per-user runtime configuration (''${HOME}/.subversion''/*)
   1. The per-user Registry values (Windows Only)
   1. Per-machine runtime configuration (''/etc/subversion/*'')

Mime
View raw message