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:

Reply via email to