This mail won't provide you the answer you hope for, but it may give you
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
people ( which is large to Belgian standards ).
We're currently in the process of migrating all our internal PVCS
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.
the teams are small, some are 20-50 people.
We have deployed one central Subversion server on Suse Linux, with
and integration to the corporate Active Directory server using OpenLDAP. We
SVNParentPath to define the location of all the repositories.
Clients are almost exclusively Windows 2000 ( we use TortoiseSVN here ),
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
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
They all reside in /[module]/branches.
3. We have 5 types of tags: releases, candidates, builds, development,
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
5. All naming, locations, log messages, roles and usage patterns are
procedures ( and applied very strictly ). We provide training for daily
and try to automate advanced usage through scripts so people don't have
6. Our svnaccess.conf is strictly structured, allowing easy copy-pasting
# 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
# rights definition for app1
@app1_admin = rw
@app1_relco = rw
@app1_dev = rw
@app1_dev = rw
The svnaccess.conf file is stored in our configuration repository, and once
it's updated on the svn server. This allows the three of us to alter the
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
This first is linking of role(group) definitions to LDAP groups.
The second is to allow matching of groups and repository folders with
My ideal svnaccess.conf would look something like this ( might not be
technically correct ):
# access definition ( where ?P<repo> is a named capturing group regex )
"cn=(?P=repo) SVN Admin,ou=groups,o=domain.com" = rw
"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.
From: qbase [mailto:firstname.lastname@example.org]
Sent: vrijdag 16 december 2005 9:52
To: André Pönitz
Subject: Re: Re: Administrate of hundreds of users, groups and
Ok, seems like it is possible to use LDAP to some extent but it's
How does other large companies or big open source projects like
Apache administrate their users, groups and ACL? Do they really administrate
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.
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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Dec 19 23:41:01 2005