Question

我们使用Subversion的方式是处理主干，功能分支用于重要功能（> 1天工作）和发布分支。

我们删除功能分支一旦他们愉快地合并，但我们希望保留发布分支，以防错误修复等需要它们。

我们每个人都至少检查项目的根目录，因此我们都拥有整个目录结构的副本（主干，分支，发布）。尽管我可以教育人们检查他们是否正在对着行李箱进行操作，但他们最终可能会意外地对抗发布分支。

防止这种情况发生的最佳方法是什么？我正在考虑锁定发布分支中的所有文件，这会有帮助吗？还有哪些其他选择？

Answer 1

为什么每个人都检查出整个SVN层次结构？如果每个人都只检查了他们正在处理的主干/分支，那么它将更不容易出错。您无法检查未检出的分支中的某些内容。

我可以按照Razzie提到的标记发布的方式进行练习。

Answer 2

我不知道有任何内置的方法来积极防止这种情况发生。您可以使用“存储库预挂钩”来执行此操作。这是一个在每次提交之前运行的小程序。如果失败，则整个提交失败。请参阅Subversion书中的the chapter on hooks。

你的钩子脚本会检查要提交的路径，并禁止一些。这可能有所帮助： http://metacpan.org/pod/SVN::Hooks

那就是说，你真的确定要这么做吗？

我们也使用发布分支，我们做偶尔检查一下它们，通常是那些无法立即升级到最新版本的客户的关键错误修正。你确定你永远不需要吗？

Answer 3

不要浪费时间试图阻止这种情况发生。如果开发人员在错误的分支上进行更改，只需在发生错误时将其还原，并确保将其传达给开发人员。

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

Answer 4

我认为删除'发布分支'并将它们变成标记是一个好习惯，因为这是标记的目的。

这并没有真正解决问题，尽管它可能会阻止更多这些事故，因为你永远不应该在标签中工作。我同意brendin，如果它仍然发生，还原那些变化，并踢开发者： - ）

Answer 5

为什么使用分支作为标记？我建议：

本地开发标准（即不要在我们要求您不提交的情况下提交）
Subversion进修培训（即为什么开发人员检查整个回购？）
使用标签结构来实现预期目标

话虽如此，并假设您的存储库层次结构布局为：

* repo
  - tags
  - trunk
  - branches

虽然SVN Book以这种方式反对粒度控制，但您也可以使用svn_access_file来阻止对分支上的任何内容进行提交？例如：

[repo:/]
@developers = rw

[repo:/branches]
@developers = r
@rel_engineers = rw

如果您希望开发人员能够创建分支，那么您将不得不单独进入每个分支（这可以回到SVN Book首先建议反对该方法的前提）。

使用Subversion防止分支更改的最佳方法

5 个答案: