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=21&rev2=22 Comment: 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 [[http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_subr/config_file.c|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 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: @@ -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 === * http://subversion.tigris.org/issues/show_bug.cgi?id=1974 @@ -114, +156 @@ * [[http://svn.haxx.se/dev/archive-2005-05/1291.shtml|"Repository-defined autoprops"]] list discussion * [[http://svn.haxx.se/dev/archive-2005-05/0889.shtml|"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". -
