我们已经开始在工作中使用功能分支模式。
一切似乎都运转良好，这是我们使用的步骤：
开发人员具有对branches文件夹的读/写访问权限，对标记和trunk的读访问权
维护者对所有文件夹具有读/写权限
我们使用svn 1.5.1（受服务器限制为Ubuntu Server 8.04），尽管我们正在使用最新的svn迁移到最新的服务器（Ubuntu Server 12.04）。
客户端我们TortoiseSVN 1.7.6，svn客户端版本1.7.4。
到目前为止，一切运行良好，我们有多个开发人员同时编写功能。
然而，目前我是唯一被提名的维护者，一旦该过程被敲定并且人们接受了足够的培训，其他人将被提名。
我担心的是，这个过程变得更加自主，我的直接参与减少了以下可能发生的情况，我不知道如何预防它们：
我在Tortoise或SVN中看不到任何警告或阻止你这样做的事情。
然后，我还没有尝试过任何令人讨厌的东西只是为了看它是做什么的。
如何自动阻止用户进行这些错误提交？
答案 0 :(得分：2)
看起来你会喜欢Subversion 1.8中的automatic merges。
检查SVNBook章节"Reintegrating a Branch"。如本章所述，您可以在完成后删除重新整合的分支。
然而：
如果您选择在将分支重新集成到分支后不删除分支 trunk 您可以继续从主干执行同步合并然后 再次重新整合分支。如果您这样做，只有更改 在第一次重新整合后合并到你的分支上 中继线。
答案 1 :(得分：2)
我们遇到了类似的问题并以组织的方式解决了这个问题：当一个分支最终在主干中合并时，它将在团队会议中进行通信，然后分支将被重命名，因此所有现有的结账都是“死了“ - 不小心办理入住手续。效果非常好（在我们的团队中）。
答案 2 :(得分：2)
我在分支的重新集成（对于1.7.X SVN）中看不到任何坏事 - --reintegate不会将分支转换为非功能性子树，下一次合并只是提交分支中的更改
而且，如果中继线未与分支范围同步，则BTW merge --reintegrate将失败。
作为最后的手段，对于从存储库中删除的每个人或分支重新集成到RO后，可以限制功能分支的ACL