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 CMichaelPilato
Date Mon, 19 Dec 2011 17:49:16 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=19&rev2=20

Comment:
Add some notes about the more obvious API changes that would be required.

  
  We plan to introduce a new capability string ("server-config") which clients should use
to announce to the server that they will honor the server's dictated configuration.  Administrators
may choose to use that string presence/absence in the list of capabilities passed to the start-commit
hook to determine whether to allow commits from certain clients.
  
- === Server-side storage ===
+ === Server-side Changes ===
  The most logical format for server-side configuration is to use the INI file format[1] which
is already employed for several other purposes across Subversion.  And the most logical location
to put those INI files is in ''${REPOS_PATH}/conf/'' somewhere.
  
  [1]The actual syntax is documented in the default README file created by Subversion in the
per-user configuration area (e.g. %APPDATA%\Subversion\README.txt on Windows and ~/.subversion/README
on *nix) or can be found in the Subversion source code in [[http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/config_file.c|config_file.c]]
-- see svn_config_ensure().
  
- === Client-side storage ===
+ === Client-side Changes ===
+ ==== API changes ====
+ svn_ra_callbacks2_t (svn_ra.h) will grow two new callback functions:
+ 
+ {{{
+ /* Set CHECKSUM to the SHA1 checksum of the locally cached repository
+    configuration for the repository identified by REPOS_UUID, allocated
+    from POOL. */
+ svn_error_t *
+ repos_config_cache_get_checksum(svn_checksum_t **checksum,
+                                 const char *repos_UUID,
+                                 void *baton,
+                                 apr_pool_t *pool);
+ 
+ /* Store the contents of REPOS_CONFIG as the current repository
+    configuration of the repository identified by REPOS_UUID.  Use
+    SCRATCH_POOL for temporary allocations. */
+ svn_error_t *
+ repos_config_cache_set(const svn_string_t *repos_config,
+                        const char *repos_UUID,
+                        void *baton,
+                        apr_pool_t *scratch_pool);
+ }}}
+ svn_ra_open4() will call the repos_config_cache_get_checksum() callback as soon as it knows
the repository UUID.  That might be immediately (because the client has provided the repository
UUID via that function's parameters for the purposes of validation against the server), or
it might be after some server communication (which, among other things, will provide the repository
UUID).
+ 
+ svn_ra_open4() will call the repos_config_cache_set() callback if/when a new repository
configuration is delivered from the server to the client.
+ 
+ Of course, we'll need implementations (in libsvn_client/ra.c) of both of these callbacks.
+ 
+ ==== Cache storage ====
  The client current maintains a 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:
  
  {{{
@@ -54, +83 @@

  ...
  $
  }}}
- === Configuration Hierarchy ===
+ ==== Configuration hierarchy ====
  Server-dictated configuration will be the highest priority configuration recognized by well-behaved
Subversion clients, excepting per-use overrides (ala --config-option).  Only specific options
will be made available for server-dictated configuration though.  Also, only certain of the
server-dictated configuration options will be overridable at all.  These details will be governed
by hardcoded client-side whitelists.
  
  So, the order in which specific configuration options will be honored where found is:

Mime
View raw message