RE: Re: Administrate of hundreds of users, groups and projects?

Markus,
 

This mail won't provide you the answer you hope for, but it may give you
ideas.

I'm part of a team of 3 people handling amongst a lot of other things the
administration of the Subversion repositories. Size of our IT departement is
500+
people ( which is large to Belgian standards ).
We're currently in the process of migrating all our internal PVCS
repositories
to Subversion. At this time, we trained some 150 developers working on 10
repositories. In total, we will have appr. 300 users on 50 repositories.
Most of
the teams are small, some are 20-50 people.
 
We have deployed one central Subversion server on Suse Linux, with
Apache/http
and integration to the corporate Active Directory server using OpenLDAP. We
use
SVNParentPath to define the location of all the repositories.
Clients are almost exclusively Windows 2000 ( we use TortoiseSVN here ),
some XP
or Suse.
 
We're doing administration of the authorization by hand, by altering one big

svnaccess.conf file. Current time spent daily is max. 15 minutes.
 
We introduced some basic principles and standards to help us keep the
overhead
low, in absence of a better ( and complete ) automated solution:
1. We defined five types of user roles: developer, bugfixer, build user,
   release coordinator and repository admin.
2. We have 7 types of branches: dev, maint, hotfix, datafix, feature, vendor
& trunk.
   They all reside in /[module]/branches.
3. We have 5 types of tags: releases, candidates, builds, development,
datafixes.
   They all reside in a subfolder under /[module]/tags.
4. Each type of branch has its own policy, including type of commit ( merge
only / MYOC )
   and the roles we allow right access. Creation of tags is equally limited
to certain
   roles.
5. All naming, locations, log messages, roles and usage patterns are
documented in
   procedures ( and applied very strictly ). We provide training for daily
usage though
   and try to automate advanced usage through scripts so people don't have
to learn
   all procedures.

6. Our svnaccess.conf is strictly structured, allowing easy copy-pasting
   [groups]
   # group definition for app1
   app1_dev = @app1_relco, account1, account2
   app1_bugfixer = @app1_dev
   app1_build = ccuser
   app1_relco = account3
   app1_admin = account4
   # end of group definition for app1
   ...
   
   and
   
   # rights definition for app1
   [app1:/]
   @app1_admin = rw
   
   [app1:/tags/releases]
   @app1_relco = rw
   
   [app1:/branches/DEV_V0001.00.00]
   @app1_dev = rw
   
   [app1:/branches/DEV_V0002.00.00]
   @app1_dev = rw
   ...
    
The svnaccess.conf file is stored in our configuration repository, and once
committed
it's updated on the svn server. This allows the three of us to alter the
file without
risk of losing changes.

Disadvantages of this setup are:
1. Since we assign roles to branches, whenever a team needs a new branch
they have to
   contact us and ask to assign the correct policy.
2. Although there's three of us, we're still a single point of failure.
3. There's duplication in definition of groups, because they're already
defined in AD.
   We have to keep them uptodate in svnacess.conf as well.
4. 'Manual labour' is time consuming and error-prone.
   
Like I said, don't see this as the solution for your problem. In fact, I
would be most
happy if other people could help us improve the above procedure.

With two new features added to Subversion I think all this could be
automated.
This first is linking of role(group) definitions to LDAP groups.
The second is to allow matching of groups and repository folders with
regular expressions.

My ideal svnaccess.conf would look something like this ( might not be
technically correct ):

[groups]
#empty

# access definition ( where ?P<repo> is a named capturing group regex )
[(?P<repo>.*):/]
"cn=(?P=repo) SVN Admin,ou=groups,o=domain.com" = rw

[(?P<repo>.*):/branches/DEV_(.*)]
"cn=(?P=repo) SVN Developer,ou=groups,o=domain.com" = rw
...

It seems there is already a regex patch on the dev mailing list. If I find
some time I'll
open a discussion there to find out how we can progress on this topic.

regards,

Lieven.

________________________________

        From: qbase [mailto:qbase77@gmail.com]
        Sent: vrijdag 16 december 2005 9:52
        To: André Pönitz
        Cc: users@subversion.tigris.org
        Subject: Re: Re: Administrate of hundreds of users, groups and
projects?
        
        
        Ok, seems like it is possible to use LDAP to some extent but it's
not ideal(IMHO).
        How does other large companies or big open source projects like
Apache administrate their users, groups and ACL? Do they really administrate
this manually?
        
        Our solution will be placed outside our Intranet and it will have is
own authentication. Because the developers comes from different companies
and much of the material must be held secret between projects.
        
        /Markus

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.14.1/206 - Release Date: 16/12/2005
 
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org