Welcome!

Web 2.0 Authors: Greg Schulz, Roger Strukhoff

Blog Feed Post

Getting Started: Subversion Permissions

A few months ago, I posted some of the differences between Git and Subversion. In summary: Git and Subversion are different version control systems with different strengths. Neither one is a best fit for every project; you’ll get the best results by examining your team’s needs and choosing the system that is the best fit.

As I mentioned in my prior post, one of the key differences between Subversion and Git is that Subversion knows how to manage fine-grained permissions for your users. So for instance, you can specify that contractors do not have access to code other than their subcomponent, or that new team members have read-only rights on sensitive parts of the repository, or whatever combinations make sense for your workplace.

Subversion has a server-side mechanism that enforces permissions, so that the enforcement is secure and transparent to your users. If you’re managing your own Subversion server, check out the Subversion book section on Path-Based Authorization for details on how to configure feature. If you’re using ProjectLocker, keep reading for an easier way to manage your Subversion Access Control Lists (ACLs).

To get to the Web interface for managing ACLs:

  1. Login to ProjectLocker Portal.
  2. Click the Projects link in the navigation bar at the top of the screen.
  3. Locate the relevant project and click the gear icon next to it (in the Action column).
  4. Click the Manage SVN Permissions menu item.

The Subversion Permissions screen gives some background on how to specify and edit permissions. But it’s easy enough to just dive in and start setting permissions. To get a flavor for how the ACL editor works, go ahead and click the root path (”/”) link, or the details icon to its right. Now you’ll see a screen like this one:

As you can see, three of my users currently have read and write access to everything in the root directory. Since Subversion permissions roll down, this automatically applies to all subdirectories unless there is a contradicting rule. If you open the dropdown at the bottom, you will see a list of your users, who you can give specific permissions as necessary. There’s also the shorthand entry of *, which means any user.

Now, let’s say we want to prevent me (runako) from having write access to the /branches/2013_Releases folder. We’d enter the new path in the path section below and click add:

Then we’d click the link for the new directory to get to the ACL for that directory. Choose runako from the dropdown at the bottom and add my user to the list. Then, check only the Read checkbox for my user and save the changes. You’ll end up with something that looks like this:

And that’s all there is to it, no code or multiple repository gymnastics required. If you find yourself frequently setting permissions for groups of users, you can use the groups feature to assign users to logical groups, which you can use in creating ACLs. And we’re always here to help if you have any questions, just reach out to us via email, chat, or Twitter (@ProjectLockerHQ).

Read the original blog entry...

More Stories By Damon Young

Damon Young is Director of Sales at ProjectLocker.com. ProjectLocker was founded in 2003 to provide on-demand tools for software developers. Guided by the simple mission of helping companies build better software, ProjectLocker's services have expanded to include services for the complete lifecycle of software projects, from requirements documentation to build and test automation. ProjectLocker serves companies from startups to Fortune 1000 multinationals.