Darix just brought up an interesting point about the way authz works in
mod_authz_svn and svnserve.
In mod_authz_svn, repositories can only be served at a depth of zero or
one directories (respectively SVNPath and SVNParentPath). So in authz
configurations you only get two cases:
[/path/in/repos]
...
and
[repos_name:/path/in/repos]
...
Now, we have authz in svnserve. In svnserve, a repository can be served
at any depth, so you could also get:
[repos_path/repos_name:/path/in/repos]
...
However, the current code in svnserve takes only the last component of
the path to make the repository name. Thus, a setup which serves
/groupa/repos and /groupb/repos would have overlapping authz rules for
both repositories, if both repository configurations point to the same
authz configuration.
Okay, I'm not being very clear here. Say you have two repositories:
/srv/svn/groupa/repos and /srv/svn/groupb/repos. Both are served by
svnserve -r /srv/svn, and in both repositories, svnserve.conf lists
"authz-db = /srv/svn/authz.conf". For both repositories, svnserve
thinks that both are called 'repos', and thus, no possibility to discern
between them in the authz rules.
This case seems fairly rare in actual fact. Big hosts like BerliOS have
unique project names, and just partition them into different directories
for efficiency. However, there are cases where this could lead to
serious confusion.
I'm not really sure how to handle this gracefully. There are two
options as I see it:
1. Document the limits of authz as applied to svnserve, and hope that
the collision situation is rare enough to not bother anyone.
2. Make mod_dav_svn and mod_authz_svn handle n-depth repositories when
serving SVNParentPath, and make svnserve handle n-depth authz like it
should. This makes svnserve and mod_dav_svn serve repositories equally,
and enables both having the same authz rules and general setup if the
repositories have to be served from both RA methods.
My view is that 2. is the right thing to do, because it makes authz
equal and uniform accross RA methods. It seems that mod_dav_svn was
made to prevent n-depth repositories by design though. Can someone in
the know tell me why that is? This fix would also require altering
dav_svn_split_uri(), which likely has a lot of repercussions all over
mod_dav_svn.
Also, 2. will take more time than amending the svnbook as 1. requires.
Is there enough time to get this fix (if it is deemed necessary and
possible) into 1.3.0 ? The alternative, if the fix is not possible
before 1.3.0, would be to document the lack in svnserve for 1.3.0 and
work out a durable solution for the next release.
What do people think?
- Dave.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Oct 10 00:18:12 2005