subversion-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache subversion Wiki <>
Subject [Subversion Wiki] Update of "ServerDictatedConfiguration" by CMichaelPilato
Date Tue, 20 Dec 2011 15:57:19 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:

After conversation with pburba, move from a server-push to a client-pull sync model.  It makes
for a cleaner API, and only costs an extra network turnaround if/when the server config changes.

  The configuration the server dictates can at best be only a suggestion to the client. Older
clients will obviously not even understand the new dictates.  As open source software, though,
it is relatively easy for a malicious user to modify a client to ignore server-side suggestions.
 Given this reality, server-side enforcement of desired behaviors (where possible, and often
via hook scripts) is still strongly recommended.
  === Server-client transmission mechanism ===
- Over ra-neon/ra-serf, the client will send to the server the sha1 hash of the server-dictated
config that it currently has cached as part of the OPTIONS request.  If the server has a different
version, it will send that to the client in the OPTIONS response.  For ra-svn, a similar thing
happens as part of the initial connection handshake/feature exchange.  This is an opportunistic
caching approach, keeping the client in sync with the repository configuration any time the
client contacts the repository.  This mechanism requires that there exist a predictable and
consistent manner in which to calculate the checksum of the configuration.
+ When connecting to a server which supports this feature, the server will provide to the
client a SHA1 checksum of its configuration.  A supporting client may then use that checksum
(and the UUID of the repository) to compare against its own cached copy of the server configuration.
 If the checksums differ, the client will request a new configuration from the server.
+ Over ra-neon/ra-serf, the client will receive the server'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
server's checksum delivery, and a new query for the configuration fetch.
  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 Changes ===
+ ==== Configuration storage ====
  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 [[|config_file.c]]
-- see svn_config_ensure().
  === Client-side Changes ===
  ==== API changes ====
- svn_ra_callbacks2_t (svn_ra.h) will grow two new callback functions:
+ svn_ra_open5 (svn_ra.h) will be introduced, differing from its predecessor by the addition
of an svn_checksum_t ** return value.
- /* Set CHECKSUM to the SHA1 checksum of the locally cached repository
-    configuration for the repository identified by REPOS_UUID, allocated
-    from POOL. */
+ /**
+  * Open a repository access session to the repository at @a repos_URL,
+  * or inform the caller regarding a correct URL by which to access
+  * that repository.
+  *
+  * If @a repos_URL can be used successfully to access the repository,
+  * set @a *session_p to an opaque object representing a repository
+  * session for the repository and (if @a corrected_url is non-NULL)
+  * set @a *corrected_url to NULL.  If there's a better URL that the
+  * caller should try and @a corrected_url is non-NULL, set
+  * @a *session_p to NULL and @a *corrected_url to the corrected URL.  If
+  * there's a better URL that the caller should try, and @a
+  * corrected_url is NULL, return an #SVN_ERR_RA_SESSION_URL_MISMATCH
+  * error.  Allocate all returned items in @a pool.
+  *
+  * If @a config_checksum is not NULL, set @a *config_checksum to the SHA1
+  * checksum of the repository's configuration.  (Clients should use this
+  * value to determine if they need to request an updated copy of the
+  * server-side configuration via @c svn_ra_get_repos_config().)
+  *
+  * Return @c SVN_ERR_RA_UUID_MISMATCH if @a uuid is non-NULL and not equal
+  * to the UUID of the repository at @a repos_URL.
+  *
+  * @a callbacks/@a callback_baton is a table of callbacks provided by the
+  * client; see @c svn_ra_callbacks2_t.
+  *
+  * @a config is a hash mapping <tt>const char *</tt> keys to
+  * @c svn_config_t * values.  For example, the @c svn_config_t for the
+  * "~/.subversion/config" file is under the key "config".
+  *
+  * All RA requests require a session; they will continue to
+  * use @a pool for memory allocation.
+  *
+  * @see svn_client_open_ra_session().
+  *
+  * @since New in 1.8.
+  */
  svn_error_t *
- repos_config_cache_get_checksum(svn_checksum_t **checksum,
-                                 const char *repos_UUID,
-                                 void *baton,
+ svn_ra_open5(svn_ra_session_t **session_p,
+              const char **corrected_url,
+              svn_checksum_t **config_checksum,
+              const char *repos_URL,
+              const char *uuid,
+              const svn_ra_callbacks2_t *callbacks,
+              void *callback_baton,
+              apr_hash_t *config,
-                                 apr_pool_t *pool);
+              apr_pool_t *pool);
+ }}}
+ Of course, svn_ra_open4() will then be deprecated and made into a wrapper around svn_ra_open5()
which passed NULL for the 'config_checksum' parameter.
- /* Store the contents of REPOS_CONFIG as the current repository
-    configuration of the repository identified by REPOS_UUID.  Use
-    SCRATCH_POOL for temporary allocations. */
+ Additionally, we'll introduce a new API function, svn_ra_get_repos_config():
+ {{{
+ /* Set *repos_config to a string representing the repository configuration
+    for the repository associated with RA_SESSION, allocated from POOL. */
  svn_error_t *
- repos_config_cache_set(const svn_string_t *repos_config,
+ svn_ra_get_repos_config(const svn_string_t **repos_config,
+                         svn_ra_session_t *ra_session,
-                        const char *repos_UUID,
-                        void *baton,
-                        apr_pool_t *scratch_pool);
+                         apr_pool_t *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
- 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:
@@ -100, +141 @@

   1. New Server-Side Enforcement: Other than the existing hook script infrastructure there
are no plans for additional server-side enforcement of the server-dictated configuration.
   1. True Server-Wide Config: Setting a consistent configuration for all repositories on
a given server will be accomplished by using consistent configs for each repository; there
are no plans for a dedicated server-wide config. Administrators are already used to  having
 configuration duplicated across many repositories (hook scripts,  authz  files, etc.), so
we suspect it's no showstopper if "server"   configuration is done by ensuring that every
repository is properly   configured.
+  1. Reworking the client-side local configuration to support similar hierarchies of configuration.
 Today, the local configuration is largely universal in terms of remote scope -- changes to
the configuration apply to all working copies of all repositories on all servers.  (Some exceptions
exist in the 'servers' file, but those are largely disinteresting for our purpose.)  If the
client had access to hierarchical configuration, users could configure such things as "in
all working copies of ${ASF_REPOS_UUID}:/subversion, do not store pristines".
  === Related Issues ===
@@ -114, +156 @@

   * [[|"Repository-defined autoprops"]]
list discussion
   * [[|"Inherited properties document]]
list discussion
- == Random thoughts ==
-  * A way to inject configuration directives client-side?  Use-case: "In all working copies
of /repos/asf/subversion, do not store pristines".

View raw message