2012/1/4 Paul Burba <ptbu...@gmail.com>: > Mike Pilato and I have been kicking around some ideas on server > dictated configuration recently and have put our thoughts into a wiki > (full disclosure: this wiki was initially based on Hyrum's thoughts on > the subject in > https://svn.apache.org/repos/asf/subversion/trunk/notes/repos-dictated-config) > : > > http://wiki.apache.org/subversion/ServerDictatedConfiguration > > We're at a point where it's time to solicit some wider feedback, so > please have a look at the wiki and follow-up here with any concerns, > thoughts, suggestions, etc.. >
1. I do not see path-based authorization being mentioned. The proposal says that "The current plan is to allow configuration at the most granular level, per repository-path". It means that path-based authorization must be applied to it and it must hide the configuration for those parts of repository that are not readable by the current user. I do not see how it plays with proposed "Server-client transmission mechanism" that uses a checksum and configuration caching at the client. If admin gives an user additional rights, so that she now sees a part of repository that she did not see before, does she need to reread the configuration? How a client can know that? Will the checksum change? Should the checksum depend on the path that is accessed by the client? 2. Note that TortoiseSVN already implements certain server-dictated configuration options. Documentation: [1] http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-dug-propertypage.html#tsvn-dug-propertypage-tsvn-props In short: 1) They are implemented as svn properties that are set on directories 2) Notable ones are: - tsvn:logminsize sets the minimum length of a log message for a commit - tsvn:autoprops overrides Subversion' autoprops setting - tsvn:projectlanguage sets language that is used when spellchecking the log message - bugtraq:* properties provide intergration with bug tracking software. I like this feature but a drawback in the current implementation is that the properties must be present in the user's WC. If I checkout a subfolder of the original project and the properties are not set on that folder then TortoiseSVN does not see them. I think that now with WC-NG this drawback can be cured by the following change: - Allow the WC to know the properties not only of its subtree, but also of its parent folders up to the repository root. Mechanism to send configuration updates to the client: The client should update the root folder of its WC. When the root folder of WC is updated, the changes in the properties of its parent directories could be sent as well. Mechanism to enforce configuration updates: I think that it could be similar to what happens when you try to commit property changes on a directory. If your directory is not up to date the commit is rejected and you are asked to update your WC. I think that to ask the server for the properties of those parent folder the client can use the same protocol that is used in sparse checkouts. That is if it were a sparse checkout starting from the repository root. The only difference is that the parent folders are not actually present on the user's hard drive. (The client should use this feature only on svn 1.5 and later servers, because the feature needs proper server-side support of sparse checkouts.). Best regards, Konstantin Kolinko