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

Question

We started using the function branch template here at work.

Everything works well, here are the steps we use:

• Extension of developer branches
• Developer (s) completes implementation and testing using branch
• The developer merges the trunk into a branch, making the branch ready for reintegration.
• Container reintegrates branch into trunk
• Version, build and tag.

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

Parents have read / write access to all folders

We are using svn 1.5.1 (limited to server to Ubuntu Server 8.04), although we are in the process of upgrading to an updated server (Ubuntu Server 12.04) with an updated svn.

Client us TortoiseSVN 1.7.6, svn client version 1.7.4.

So far, everything is working well, and we have several developers, all recording functions at the same time.

However, at the moment, I am the only designated attendant, others will be appointed after the process is knocked out, and people will be trained at a sufficient level.

My problems are that one process becomes more autonomous, and my direct participation is reduced, the following scenarios are possible, and I can’t say how to prevent them:

• The developer forgets that the branch has been reintegrated and accidentally commits with it.
• The maintainer does not check the adequate branch and is ready for reintegration and performs reintegration and fixation.

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

And again, I did not try to do anything contrary to see what he was doing.

How can I automatically prevent users from committing these bad commits?

Answer 1

It looks like you will love the automatic merge in Subversion 1.8.

Check out the SVNBook Reintegrate Branch section. As stated in the chapter, you can delete a reintegrated branch after you are done with it.

But:

If you decide not to delete your branch after reintegrating it into trunk, you can continue to synchronize with the trunk, and then return the branch again . If you do this, only the changes made on your branch after the first reintegration merge with the Trunk.

Answer 2

We had some similar problem and solved it in an organizational way: when the branch is finally merged in the trunk, it will be handed over to the team meeting, and then the branch will be renamed, so that all existing checks will be "dead" - random checks are impossible. It works very well (in our team).

Answer 3

I see nothing wrong with more than a single branch reintegration (for 1.7.X SVN). --reintegate does not convert a branch to a non-functional subtree, the next merge just commits changes to the branch

And, BTW, merge --reintegrate will fail if the trunk is not synchronized with branch ranges.

As a last resort, the ACL for the function branch may be limited after reintegration into the RO for all, or the branch may be removed from the repository.