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 Tue, 03 Jan 2012 22:57:37 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=31&rev2=32

Comment:
Note that store-plaintext-passwords is per-repostiory when discussing cached config file.

  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''' ||
- 
- ||<tablestyle="width: 793px; height: 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. ||
+ ||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 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?||
+ ||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? ||
- ||New capability for each patch release (e.g. "client-version-1.8.0")||Ditto, but if knowing
the minor release is good, kowing the patch release must be better no?||
+ ||New capability for each patch release (e.g. "client-version-1.8.0") ||Ditto, but if knowing
the minor release is good, kowing the patch release must be better no? ||
  
  
  
@@ -112, +111 @@

                          apr_pool_t *pool);
  }}}
  ==== Cache storage ====
- The client currently maintains its configuration in two files, ''${HOME}/.subversion/confi''g
and ''${HOME}/.subversion/servers''.  This feature will introduce the ''${HOME}/.subversion/repos/''
directory (%APPDATA%\Subversion\repos on Windows), which will hold additional subdirectories
keyed on the UUID of the repository.  It is in this subdirectory that the cached version of
the repository configuration will be stored.  To facilitate path-specific configuration within
a repository, the typical section names of the configuration bits will be combined with the
subtree path to which the options therein apply.  For example:
+ The client currently maintains its configuration in two files, ''${HOME}/.subversion/confi''g
and ''${HOME}/.subversion/servers''.  This feature will introduce the ''${HOME}/.subversion/repos/''
directory (%APPDATA%\Subversion\repos on Windows), which will hold additional subdirectories
keyed on the UUID of the repository.  It is in this subdirectory that the cached version of
the repository configuration will be stored.  To facilitate path-specific configuration within
a repository, the typical section names of the configuration bits will be combined with the
subtree path to which the options therein apply (this will not apply for the store-plaintext-passwords
configuration option, which is per-repository).  For example:
  
  {{{
  $ cat ${HOME}/13f79535-47bb-0310-9956-ffa450edef68/config

Mime
View raw message