RE: Operational restrictions in svn?

The issue is really just that our management want some assurances that no developer can, either maliciously or accidentally, create branches or perform wide-ranging merges within the repository. Essentially, they just want the developers to have access to check out their files and commit their changes, and they'd prefer to centralize (e.g., through a sys admin or buildmaster) any other operations that can identify specific release points (tagging), create source branches, etc.

I agree that most of this can be handled simply through training and documentation of proper procedures, but they'd prefer to be able to have something more explicit than that.

-----Original Message-----
From: Ben Collins-Sussman [mailto:sussman@collab.net]
Sent: Thursday, November 04, 2004 4:51 PM
To: Steve Cramer
Cc: users@subversion.tigris.org
Subject: Re: Operational restrictions in svn?

On Nov 4, 2004, at 4:45 PM, Steve Cramer wrote:
>
>  
> Has anybody else tried to implement these sorts of operational
> restrictions with Subversion?  Any thoughts on possible solutions?
>

I have to admit, I don't quite understand the problem here. You
currently have the ability to control each user's ability to read or
write any path in the repository. Why do you need to control the
specific client commands that users run? Why does that matter, since
the ultimate result of any command is a read or write to the
repository?

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 5 03:18:44 2004