Peculiarities of Subversion Path Based Authorization
If you're using Subversion in a corporate environment you might need to rely on path based authentication to revoke users' read or write access to parts of a repository. Unfortunately the feature is not documented very well and there are a couple of specifics you should be aware of in advance to prevent unpleasant surprises later. I decided to describe two of them that I recently stumbled upon.
- Path based permissions are stored completely separate from the repository and Subversion operations are not aware of them apart from the authentication itself before the operation starts. This behavior has important implications when moving branches around the repository: the permissions are not moved along with the branches but stay associated with the original location instead. You need to keep this in mind when you have a fixed path to a branch which is frequently replaced, e.g. a release candidate branch. If you set permissions to it they will stick with that path even when you archive the current release candidate branch to another location and put a new branch from trunk in its place. The permissions will now be granted to the new release candidate branch and not the old one that you have moved away. This might even be the desired behavior in your case, just be sure you know about it.
- When moving branches around the repository their history from before the move stays associated with its original location. To view it, the user needs read permissions for that path as well even when invoking the log from the new location. When applying this to the previous example, it means that to view the complete history of the release candidate branch the user needs read permissions to trunk, otherwise he will only see the part of the history that happened after the move without being even warned that some part of the history is not visible to him.
The most important advice that I can give you when using path based authentication is to always test the settings before you start using them in production environment. I suggest you assign permissions only to groups so that you can easily have a test user which you can put in different groups to test the experience any user in this group is going to have.
