How can I prevent people from using reintegrated branches in SVN?

Question

We've started using the feature branch pattern here at work.

Everything appears to be working well, here's the steps we use:

1. Developer branches trunk
2. Developer(s) complete implementation and testing using the branch
3. Developer merges trunk into branch, bringing the branch up to date ready for reintegration
4. Maintainer reintegrates branch into trunk
5. Version, build and tag.

Developers have read/write access to the branches folder, read access to tags and trunk

Maintainers have read/write access to all folders

We use svn 1.5.1 (limited by on the server to Ubuntu Server 8.04), although we're in the process of moving to an up to date server (Ubuntu Server 12.04) with up to date svn.

Client us TortoiseSVN 1.7.6, svn client version 1.7.4.

So far, everything is working well and we have multiple developers all writing features at the same time.

However at the moment I'm the only nominated maintainer, other will be nominated once the process is hammered out and people have been trained to an adequate level.

My concerns are that one the process becomes more autonomous and my direct involvement is reduced the following scenarios may occur and I can't tell how to prevent them:

1. Developer forgets that a branch has been reintegrated and accidentally commits work to it
2. Maintainer doesn't adequately check that a branch is up to date and ready for reintegration and performs a reintegrate and commit.

I can't see anything in Tortoise or SVN that warns or prevents you from doing this.

Then again, I haven't tried to commit anything nasty just to see what it does.

How can I automatically prevent the users from making these bad commits?

Answer 1

It looks like you are going to love automatic merges in Subversion 1.8.

Check the SVNBook chapter "Reintegrating a Branch". As specified in the chapter, you can remove reintegrated branch after you are done with it.

However:

If you choose not to delete your branch after reintegrating it to the trunk you may continue to perform sync merges from the trunk and then reintegrate the branch again. If you do this, only the changes made on your branch after the first reintegrate are merged to the trunk.

Answer 2

I can't see anything bad in more-than-single reintegration of branch (for 1.7.X SVN) - --reintegate does not convert branch into non-functional subtree, next merges just commit changes in branch

And, BTW, merge --reintegrate will fail, if trunk will have not synced with branch ranges.

As last resort, ACL for feature-branch can be restricted after reintegration to RO for everybody or branch deleted from repository

Answer 3

We had some kind a similar problem and solve it on an organizational way: when a branch is finally merged in trunk it will be communicated in team meeting and then the branch will be renamed, so in this way all existing checkouts are "dead" – accidentally check-ins are not possible. Works very well (in our team).