[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: subversion based code development/management model

From: David James <list-subversion_at_davidjamesdesign.com>
Date: 2006-08-20 01:57:51 CEST

Here is the apache block that my host provider (nexcess.net) set up
for me:

DAV svn
SVNPath /path/to/repos
# our access control policy
AuthzSVNAccessFile /path/to/svn_acl

SVNIndexXSLT "/svnindex.xsl"

# try anonymous access first, resort to real
# authentication if necessary.
Satisfy Any
Require valid-user

# how to authenticate a user
AuthType Basic
AuthName "Subversion repository"
AuthUserFile /path/to/svn_users

***

The svn_acl file is a basic access control list like this:

# Specify groups
# All users in this file must also exist in the http user file
(svn_user)

[groups]
developers = david, bob, joe

# Specify access by directory

[/]
# I can read and write everywhere
david = rw
# Everybody else can read (this is in conjunction with "Satisfy any"
which you may not want to use at all). Furthermore, to say that
everyone can read here, doesn't mean they can necessarily read in a
sub-directory -- because it may be restricted further down in this file.
* = r

[/development_branch]
# This is how you specify a group -- with the '@' sign
@developers = rw
* = r

The svn_users file is a basic htpasswd file:

htpasswd -c /path/to/svn_users my_developer

FYI: I'm not a sys admin. I got a lot of help with this one. It's
great. It gives me complete fine-grain control over the directories
in the repository.

On Aug 19, 2006, at 12:45 PM, Stephen Adler wrote:

> Guys,
>
> I want to setup the following code development/management model. To
> do so, I want to use subversion
> with the appropriate access controls.
>
> The repository layout
>
> Trunk/
> Tags/
> Branches/
>
> To create a new project, the following must be done.
>
> 1) Create a template directory layout under Trunk/
> -- Done by repository administrator
> 2) Make a branch of the inital layout into the Branches directory.
> Give Developer (group of developers)
> read/write access to the branch.
> -- Copy of initial layout into Branch done by repository
> administrator
> -- Developers have full read/write access to the Branch to code
> and develop.
> 3) When coders reach the stage of having a release candidate, they
> tell the repository administrator to
> make a release.
> 3.1) Repository administrator merges the branch into the trunk.
> -- this can only be done by the administrator
> 4) Release Candidate is made, a copy from trunk to tags is made
> -- this is only done by the release administrator. The tagged
> release has only read access.
>
>
> The idea being that there is a repository administrator who has
> full access to the repository.
> The developers only have read/write access to one designated
> branch. A release is made by
> the developers telling the repository administrator to merge the
> branch into the trunk and then
> make a copy of that into the Tags area.
>
> Developers cannot create new top level branches. Developers cannot
> merge into the trunk or make
> their own releases.
>
> My subversion repository is setup with https access. (i.e. I've
> added the appropriate modules to
> apache 2.0 daemon.) I've also setup authenticated access to the
> repository, but its only at the
> top level of the repository (i.e. at the Trunk/, Tags/ Branches/
> level) So right now, if you have
> an account on my system, you can do anything to any part of the
> repository. Basically its wide
> open and there are no access controls.
>
> Any help and/or comments are greatly appreciated.
>
> Cheers. Steve.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
Received on Sun Aug 20 01:59:13 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.