我们使用 Subversion 的方式是在主干、重要功能的功能分支（> 1 天工作）和发布分支上工作。
一旦功能分支愉快地合并，我们就会删除它们，但我们希望保留发布分支，以防错误修复等需要它们。
我们每个人都至少会检查项目的根目录，因此我们都拥有整个目录结构（主干、分支、发布）的副本。尽管我可以教育人们检查他们是否在主干上工作，但他们最终可能会意外地在发布分支上工作。
防止这种情况发生的最佳方法是什么？我正在考虑锁定发布分支中的所有文件，这有帮助吗？还有哪些其他选择？
【问题讨论】：
为什么每个人都检查了整个 SVN 层次结构？如果每个人都只检查了他们正在处理的主干/分支，那么出错的可能性就会大大降低。您无法检查尚未签出的分支中的内容。
我可以支持Razzie 提到的标记发布的做法。
【讨论】：
我不知道有任何内置方法可以主动防止这种情况。您可能可以使用“存储库预挂钩”来做到这一点。这是一个在每次提交之前运行的小程序。如果失败，则整个提交将失败。请参阅 Subversion 手册中的 the chapter on hooks。
你的钩子脚本会检查即将提交的路径，并禁止一些。 这可能会有所帮助： http://metacpan.org/pod/SVN::Hooks
也就是说，你确定要这样做吗？
我们还使用发布分支，并且我们确实偶尔将内容检查到其中，通常是对无法立即升级到最新版本的客户的关键错误修复。你确定你永远不需要那个吗？
【讨论】：
不要浪费时间试图防止这种情况发生。如果开发人员在错误的分支上进行了更改，如果发生更改，只需将其还原，并确保将其传达给开发人员。
... hack hack hack ... on branch
$ svn ci -m "Feature-1337 implemented" branch
Revision 12345
...oops...
$ svn merge -c12345 branch trunk
$ svn ci -m "moved Feature-1337 from branch to trunk" trunk
$ svn merge -c-12345 branch branch
$ svn ci -m "reverted Feature-1337 on branch. it's intended only for trunk" branch
【讨论】：
我认为删除“发布分支”并使其成为标签是一个好习惯，因为这是标签的目的。
这并不能真正解决问题，尽管它可能会防止更多此类事故，因为您永远不应该在标签中工作。我同意布伦丁的观点，如果它仍然发生，请恢复这些更改，并踢开发人员:-)
【讨论】：
为什么使用分支作为标签？我建议：
话虽如此，假设您的存储库层次结构如下：
* repo
- tags
- trunk
- branches
虽然 SVN Book 反对以这种方式进行精细控制，但您也可以使用 svn_access_file 来防止提交到分支上的任何内容？例如：
[repo:/]
@developers = rw
[repo:/branches]
@developers = r
@rel_engineers = rw
如果您希望开发人员能够创建分支，那么您必须单独进入每个分支（这又回到了 SVN 书籍的整个前提，即首先建议不要使用该方法）。
【讨论】：