repositories structure from user/access control viewpoint - how?

[lejeczek <pe...@yahoo.co.uk>]

hi everybody,

I realize this certainly is somewhere in books but I'm 
hoping few experts would not mind sharing their 
thoughts/recommendations on how to...

set up svn structure where interface to it is only http and 
flexibility + ability to finely grain user access is the key 
objective - thus pretty much ubiquity I guess.

What boggles me is - should there be one http service for 
each project? or it does not matter and one http service 
serves all this:
/projectA/{trunk,branches,tags}
/prjectB/{trunk,branches,tags}
...
etc.
still assures finely grained access to each project?
And also performance, is there a best practice to assure 
performance?
I should mention, in case it matters, that I user PAM backed 
to Apaches as auth service.

many thanks

Re: AW: repositories structure from user/access control viewpoint - how?

[lejeczek <pe...@yahoo.co.uk>]

On 09/03/16 16:44, Niemann, Hartmut wrote:
> Hi!
>
> I learned that finer-as-per-repository-grained read access is rather "expensive" in terms of server load
> because rights have to be checked for each file updated.
> So it would be best that you have separate repositories for separate "read" user groups.
Hi,
that is interesting concept but one that I don't  quite get 
- you would have different locations/namespaces pointing to 
the same target?
And these namespaces would define different type of access 
per whole groups?
>
> I have not heared about somebody who used separate HTTP servers for that, I doubt that it would help.
I see I might have been a bit vague when said - service.
What I meant was, would one use separate namespace, eg:
   <Location /dev.myproject.foo>
     DirectoryIndex disabled
     DAV svn
     ForceType text/plain
     SVNReposName ......
....
for each project if the reason was - this helps finer access 
control. Or it does not and one namespace for all 
locations/projects does the same?
many thanks
>
> Our setup is a combined redmine/svn server, where global read/write rights (per repo)
> are managed by redmine, and where necessary (in my area with about 50 projects this is exactly one
> project with a sort of paranoid leader) we use a precommit hook to restrict
> commit rights to individual subdirectories, which works quite well.
>
> Mit freundlichen Grüßen
> Dr. Hartmut Niemann
>
> Siemens AG
> MO MLT LM EN CCI 1
>

AW: repositories structure from user/access control viewpoint - how?

["Niemann, Hartmut" <ha...@siemens.com>]

Hi!

I learned that finer-as-per-repository-grained read access is rather "expensive" in terms of server load
because rights have to be checked for each file updated.
So it would be best that you have separate repositories for separate "read" user groups.

I have not heared about somebody who used separate HTTP servers for that, I doubt that it would help.

Our setup is a combined redmine/svn server, where global read/write rights (per repo)
are managed by redmine, and where necessary (in my area with about 50 projects this is exactly one
project with a sort of paranoid leader) we use a precommit hook to restrict
commit rights to individual subdirectories, which works quite well.

Mit freundlichen Grüßen
Dr. Hartmut Niemann

Siemens AG
MO MLT LM EN CCI 1