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 <topping_at_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
Received on 2010-01-10 11:30:25 CET