Ok, let me just check the scenario - I guess you're trying to isolate the developers from the trunk entirely so that no-one commits directly to trunk. I assume your platform automatically creates these branches and the developers can at some point say that they're finished with the branch and have it merged back in. So the code follows the cycle:
- Branch
- Edit
- Commit to branch
- Re-base branch from trunk
- Update trunk wc
- Re-integrate branch to trunk wc
- Commit trunk wc
I'm actually all for this, if it's the way you want to work, great.
I can't think of any reason why it would fail outright, but you must check the following things:
- No code must ever be checked in without having had a developer look at it first.
- Errors will always occur on trunk and developers may need a way to hack directly on trunk at some point.
- Even if there's no merges, if the developer didn't re-base against to the latest trunk, the reintegration may introduce subtle errors.
Point 1 is the most important. This means that when re-integration occurs, it must effectively be a no-op. If any sort of merging happens in your 2.2 step, I'd say you must throw the commit away and make the developer re-base from trunk again. Even if svn says the merge says is successful and without conflicts, you just can't trust it to have done the right thing enough to fire and forget. If you're going to automate, guarantee that what the developer committed is what gets merged, not some auto-generated hybrid.
You can check if the merge was 'clean' just by looking at the output of the merge - if any of files were 'merged' then there's a problem. If they were just updated, then you're ok.
Point 3 is interesting but is always a problem, even in normal working. In this scenario, developer A would say they're finished, re-base their working copy then spend a while checking that everything works ok. In the mean time, developer B sneaks in an update to trunk. Developer A decides that everything is ok and re-integrates. However, changes made by developer B mean that code goes screwy even though it didn't touch any files modified by dev A. Since dev A was the last to commit, they get blamed.
The assumption is that if dev A had included dev B's changes, then he would have spotted the problem. Your platform has the opportunity to spot this situation (for example, if svn-merginfo says there are trunk revisions that can be committed to the branch, then it's not up to date). However I'd also caution against creating an eternal merge cycle where it's not necessary. Perhaps give the developers a warning that a commit has been made since they re-based, but allow them to go ahead anyway.
One last note: I mentioned using svn-mergeinfo above. You cant rely on this to assume that a re-integrate merge will be ok. If you do, there'll be a race condition between making the check and committing the merge - someone could have got in in the mean time. You still need to check the output of the actual merge command to see what really happened.
Also be aware of the situation if multiple devs try to re-integrate at the same time. If you check out a fresh working copy each time, you can have as many as you like, but the commits may well fail with the old "file out of date" type error. In these situations, again, the re-integration will fail and you'll have to get the developer to re-base their branches.
All in all I like it. There's a fair bit of complication in there, but at the end of the day, that's the point of this kind of system - it deals with the complex stuff so the devs don't have to. All they have to do is keep re-basing their branches until the system lets them re-integrate successfully.