2012/1/4 Paul Burba <ptburba_at_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
Received on 2012-01-04 03:20:47 CET