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=12&rev2=13 Comment: Still thinking aloud about scopes and intensities. The high-level behavior for repository-dictated configuration is relatively simple: the repository maintains a list of configuration parameters and values, and upon request, provides these to the client who then applies them appropriately. There are a number of specific bits of configuration that existing Subversion users and administrators wish to have propagated from the server to the client. There are also different scopes at which administrators might reasonably wish to apply differing defaults for these things: server-wide, repository-wide, or local to a particular directory hierarchy within a specific repository. The following is a listing of those that we know about, with some notes about scope and desired degrees of control: + ||'''Configuration''' ||'''Scope''' ||'''Enforceability''' ||'''Notes''' || ||auto-props ||per-directory ||Enforceable via hook scripts ||Clients should be allowed to override this || + ||ignores ||per-directory ||Enforceable via hook scripts ||Client should be allowed to override this || + ||use-commit-times ||per-directory ||Unenforceable ||Client should be allowed to override this || ||log message templates ||per-directory ||Enforceable via hook scripts ||Doesn't fit the name=value configuration motif quite as readily as some of the others. Would a client need to override this? || - ||myriad authn-related stuff ||per-server, per-repos ||Un-enforceable ||Lack of enforceability plus relationship to security means that admins do not want the client to be able to trivially override this setting. Precise requirements TBD (is this a boolean "allow/disallow plaintext password caching", or "require X, Y or Z encrypted password stores", or ...? || + ||myriad authn-related stuff ||per-server, per-repos ||Unenforceable ||Lack of enforceability plus relationship to security means that admins do not want the client to be able to trivially override this setting. Precise requirements TBD (is this a boolean "allow/disallow plaintext password caching", or "require X, Y or Z encrypted password stores", or ...?) || {{{#!wiki warning The configuration the server dictates can at best be only a suggestion to the client, with well-behaving clients honoring that suggestion. As free software, though, most such clients could be modified by a malicious user to ignore server-side suggestions. Server-side enforcement of desired behaviors (where possible, and often via hook scripts) is still recommended. }}} At least one user specifically called out the need for the server to enforce adherence to the configured behaviors ''without'' requiring hook scripts to do so. For example, if the repository has a configured auto-props list, the Subversion C code is perfectly capable of validating that incoming committed items obey those settings, failing the commit otherwise. This seems like a reasonable request so long as we permit admins to specify which of their configuration settings are "suggested" versus "required" (again, taking into account that anything unenforceable can't truly be "required"). + + Subversion should recognize multiple levels of possible hierarchy in the server-side configuration: + + 1. server - Settings apply for all repositories and paths therein on the server + 1. repository - Settings apply for all interactions with the repository and the paths within it + 1. subtree within repository - Settings apply for paths at or under a given path in the repository + + And at each level, multiple degrees of insistence in the actual configuration items: + + 1. weak - The configuration value is proposed to the client, but will be overridden by any client configuration + 1. strong - The configuration value is strongly suggested by the client, and may not be overridden by well-behaved client configuration + 1. enforced - The configuration value is required and adherence to it is verified by the server logic === 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 current 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.
