Best way to prevent changes on a branch with Subversion

Question

The way we use Subversion is to work on the trunk, feature branches for significant features (> 1 days work) and release branches.

We delete feature branches once they are happily merged but we want to keep release branches around in case they are needed for bug fixes and so on.

Each of us checks out the root of the project as a minimum so we all have a copy of whole directory structure (trunk, branches, releases). As much as I can educate people to check they are working against the trunk, they could end up working against a release branch by accident.

What is the best way to prevent this from happening? I'm thinking of locking all the files in the release branch, would this help? What other options are there?

Answer 1

Don't waste your time trying to prevent this from happening. If a developer makes a change on the wrong branch, just revert it if it happens and make sure to communicate this to the developer.

... hack hack hack ... on branch
$ svn ci -m "Feature-1337 implemented" branch
Revision 12345

...oops...

$ svn merge -c12345 branch trunk
$ svn ci -m "moved Feature-1337 from branch to trunk" trunk
$ svn merge -c-12345 branch branch
$ svn ci -m "reverted Feature-1337 on branch. it's intended only for trunk" branch

Answer 2

I think it would be a good practice to remove the 'release branches' and make them a tag instead, as that's the purpose of a tag.

That doesn't really solve the problem, though it might prevent more of those accidents, since you should never work in a tag. And I agree with brendin, if it still happens, revert those changes, and kick the developer :-)

Answer 3

Why is everyone having the whole SVN hierarchy checked out? It would be much less error prone if everyone has only checked out the trunk/branches they're working on. You cannot check something in a branch you haven't checked out.

I can second the practice to tag a release as mentioned by Razzie.

Answer 4

I'm not aware of any built-in way to actively prevent this. You could probably do it using a "repository pre-hook". That's a small program that runs before every commit. If it fails, the commit as a whole fails. See the chapter on hooks in the Subversion book.

Your hook script would check the path about to be commited, and disallow some. This might help: http://search.cpan.org/~gnustavo/SVN-Hooks-0.16.52/lib/SVN/Hooks.pm

That said, are you really sure you want to do this?

We also use release branches, and we do ocassionally check things into them, usually critical bugfixes for customers who cannot upgrade to the latest version immediately. Are you sure you'll never need that?

Answer 5

Why are you using branches as tags? I would suggest:

1. Local development standards (i.e. don't commit where we ask you not to commit)
2. Subversion refresher training (i.e. why are developers checking-out the entire repo?)
3. Use the tags structure for what it was intended

That being said, and assuming that you have your repository hierarchy laid-out as:

* repo
  - tags
  - trunk
  - branches

Although the SVN Book speaks against granular control in this manner, you may also use svn_access_file to prevent commits to anything on branches? For example:

[repo:/]
@developers = rw

[repo:/branches]
@developers = r
@rel_engineers = rw

If you want developers to be able to create branches, then you'll have to descend into each branch individually (which gets back to the whole premise of the SVN Book advising against the method in the first place).