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:

Developer branches trunk
Developer(s) complete implementation and testing using the branch
Developer merges trunk into branch, bringing the branch up to date ready for reintegration
Maintainer reintegrates branch into trunk
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:

Developer forgets that a branch has been reintegrated and accidentally commits work to it
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?

Since neither automatic nor answering the main question just a comment: There is a chapter on [Keeping a Reintegrated Branch Alive](http://svnbook.red-bean.com/en/1.7/svn.branchmerge.advanced.html#svn.branchmerge.advanced.reintegratetwice) for pre-1.8 svn. Basically, you're supposed to use `--record-only` to fake-merge the revision that reintegrated branch to trunk (that revision is not and can not be merged to branch) in order to fix up the branch and prevent "bad commits". You could make that fake-merge part of your reintegration process. — valid, Nov 21 '16 at 14:52

score 2 · Accepted Answer · answered May 28 '13 at 12:46

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.

1.8's in RC2 now so it looks like moving up to this will be the solution. — RoboJ1M, May 30 '13 at 07:57

Micha · Answer 2 · 2013-05-30T08:05:32.967

2

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).

edited May 30 '13 at 08:05

answered May 28 '13 at 12:50

Micha

4,959
8
32
46

I suppose I could have the Maintainer remove rw access for the branch – RoboJ1M May 28 '13 at 13:27

score 2 · Answer 3 · answered May 28 '13 at 14:59

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

answered May 28 '13 at 14:59

Lazy Badger

87,730
7
72
97

Can you confirm that only 1.7+ does not convert branch into a non-functional state? In 1.5 --reintegrate appears to merge, but with lots of conflicts and the like. No "you can't do that yet because" errors. – RoboJ1M May 29 '13 at 15:10
I've re-read the relevant chapters on 1.5, 7, and 8 and it looks like most of the problems we may have stem from us still being on 1.5. There's very little protection for us, although it's serves us flawlessly for many years. 1.7 manual still states that branch re-integration leaves the branch in an unusable state and should be deleted. 1.8 now has a synchronous merge algorithm – RoboJ1M May 30 '13 at 08:00
@RoboJ1M - I have 1.6 and 1.7 clients, can use (and use really sometimes) reintegrated branches only in 1.7 – Lazy Badger May 31 '13 at 12:15

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

3 Answers3