Just as a FYI: the issue Rob is referring to is the (in)famous issue 3242 - "Subversion demands unnecessary access to parent directories of operations"
See http://subversion.tigris.org/issues/show_bug.cgi?id=3242 It's a long standing issue, but if I understood correctly a fix is in progress ... Regards, Johan On Sat, Jan 9, 2010 at 10:31 PM, Brian Topping <topp...@codehaus.org> wrote: > > On Jan 9, 2010, at 12:58 PM, Rob van Oostrum wrote: > > I see now. The path "/project/!svn" makes no sense. It doesn't exist in the > repository, so that rule doesn't do anything. The !svn is a SVN-internal > concept. To assign permissions to /project, you need to have to specify: > [/project] > * = r > Do a search on the old list archives on tigris for some background. If I > remember correctly, you cannot have less than global read permissions on the > repository's root if you're on SVN 1.5 or later. > > Hope this helps, > Rob > > Thanks Rob. The last note does help and that seems to be correct based on > my experimentation, but it seems to go a little further, that a user must > have the same access to the root directory as they do for the particular > directory that they are working on. So that would mean if a user in @public > has rw access to and wants to commit to /project/public_files, they have to > have write access to /project so the metadata can be updated. > For the benefit of others that may come across this in the archives, it > turns out about the only way I was able to figure out to set this up was the > following: > > [/project] > * = rw > [/project/trunk/core] > > @project-core-developer = rw > > @project-web-developer = > > [/project/trunk/web] > > @project-core-developer = > > @project-web-developer = rw > > [/project/trunk/common] > > @project-core-developer = rw > > @project-web-developer = rw > > In other words, to do an exhaustive matrix of every combination of paths and > access for every group for each path. > Granted, some or much of this information may be irrelevant outside the > Crowd environment, but the situation is worse with the stock LDAP adapters > for Apache. The can't even read groups in. > Anyway, thanks for thinking this through with me. > Cheers, Brian
