views:

248

answers:

3

We are planning on having a policy to prevent commits to trunk. All commits must happen against branches.

What should be my approach to get this done?

+2  A: 

You make me wonder what the use of trunk is, if you cannot commit to it. But pre-commit hooks offer a way to do this. See also here.

  1. Ensure that you have /usr/share/subversion/hook-scripts/commit-access-control.pl. On Ubuntu, it's in the subversion-tools package.
  2. Go to your repository directory, copy the hooks/pre-commit.tmpl script into hooks/pre-commit and make it executable.
  3. Modify it to your tastes. I think the default is sensible.
  4. Write commit-access-control.cfg in your repository directory. Something like this (untested):

[StackOverflow's parser seems to be broken, it needs a paragraph here]

[Make trunk read-only]
match = ^trunk
access = read-only
Thomas
+2  A: 

See the svn documentation. IT says both apache and svnserve support path-based authorization. Also, from the documentation:

Do you really need path-based access control?

A lot of administrators setting up Subversion for the first time tend to jump into path-based access control without giving it a lot of thought. The administrator usually knows which teams of people are working on which projects, so it's easy to jump in and grant certain teams access to certain directories and not others. It seems like a natural thing, and it appeases the administrator's desire to maintain tight control of the repository.

Note, though, that there are often invisible (and visible!) costs associated with this feature. In the visible category, the server needs to do a lot more work to ensure that the user has the right to read or write each specific path; in certain situations, there's very noticeable performance loss. In the invisible category, consider the culture you're creating. Most of the time, while certain users shouldn't be committing changes to certain parts of the repository, that social contract doesn't need to be technologically enforced. Teams can sometimes spontaneously collaborate with each other; someone may want to help someone else out by committing to an area she doesn't normally work on. By preventing this sort of thing at the server level, you're setting up barriers to unexpected collaboration. You're also creating a bunch of rules that need to be maintained as projects develop, new users are added, and so on. It's a bunch of extra work to maintain.

Remember that this is a version control system! Even if somebody accidentally commits a change to something they shouldn't, it's easy to undo the change. And if a user commits to the wrong place with deliberate malice, then it's a social problem anyway, and that the problem needs to be dealt with outside of Subversion.

Amit Kumar
Well, in the event that someone accidentally commits to trunk, I would like to know that. So, a hook is required in my case, irrespective of what it does :)
publicRavi
+1  A: 

Just write a simple post-commit hook. You can use this example for guidance http://wordaligned.org/articles/a-subversion-pre-commit-hook

In your script just check the URL where they committing to and deny all transactions that modify the trunk URL

However, you need to designate a person who could merge the branches into the trunk, your pre-commit hook should check either for master username or some other authenitcation mechanism and allow merges into the trunk

Vlad
I was thinking along the same lines. But, how would I run 'svn info' if I don't have the list of files?
publicRavi
look at the script under the link. It looks into the incoming transaction so you will see the list of files being committed before they are actually committed
Vlad