使用 Subversion 防止分支更改的最佳方法
我们使用 Subversion 的方式是在主干、重要功能的功能分支（> 1 天的工作）和发布分支上工作。
一旦功能分支愉快地合并，我们就会删除它们，但我们希望保留发布分支，以防错误修复等需要它们。
我们每个人至少都会检查项目的根目录，这样我们就有了整个目录结构（主干、分支、版本）的副本。 尽管我可以教育人们检查他们是否在主干上工作，但他们最终可能会意外地在发布分支上工作。
防止这种情况发生的最佳方法是什么？ 我正在考虑锁定发布分支中的所有文件，这有帮助吗？ 还有哪些其他选择？
The way we use Subversion is to work on the trunk, feature branches for significant features (> 1 days work) and release branches.
We delete feature branches once they are happily merged but we want to keep release branches around in case they are needed for bug fixes and so on.
Each of us checks out the root of the project as a minimum so we all have a copy of whole directory structure (trunk, branches, releases). As much as I can educate people to check they are working against the trunk, they could end up working against a release branch by accident.
What is the best way to prevent this from happening? I'm thinking of locking all the files in the release branch, would this help? What other options are there?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
为什么每个人都检查整个 SVN 层次结构？ 如果每个人都只检查了他们正在处理的主干/分支，那么出错的可能性会小得多。 您无法在尚未签出的分支中检查某些内容。
我可以支持标记版本的做法，如金酸莓。
Why is everyone having the whole SVN hierarchy checked out? It would be much less error prone if everyone has only checked out the trunk/branches they're working on. You cannot check something in a branch you haven't checked out.
I can second the practice to tag a release as mentioned by Razzie.
我不知道有任何内置方法可以主动防止这种情况。 您可能可以使用“存储库预挂钩”来完成此操作。 这是一个在每次提交之前运行的小程序。 如果失败，则整个提交都会失败。 请参阅有关钩子的章节< /a> 在 Subversion 书中。
您的挂钩脚本将检查要提交的路径，并禁止某些路径。
这可能有帮助：
http://metacpan.org/pod/SVN::Hooks
也就是说，你是吗？真的确定要这样做吗？
我们还使用发布分支，并且偶尔会检查其中的内容，通常是针对无法立即升级到最新版本的客户的关键错误修复。 你确定你永远不需要它吗？
I'm not aware of any built-in way to actively prevent this. You could probably do it using a "repository pre-hook". That's a small program that runs before every commit. If it fails, the commit as a whole fails. See the chapter on hooks in the Subversion book.
Your hook script would check the path about to be commited, and disallow some.
This might help:
http://metacpan.org/pod/SVN::Hooks
That said, are you really sure you want to do this?
We also use release branches, and we do ocassionally check things into them, usually critical bugfixes for customers who cannot upgrade to the latest version immediately. Are you sure you'll never need that?
不要浪费时间试图阻止这种情况的发生。 如果开发人员在错误的分支上进行了更改，则只需将其恢复即可，并确保将其传达给开发人员。
Don't waste your time trying to prevent this from happening. If a developer makes a change on the wrong branch, just revert it if it happens and make sure to communicate this to the developer.
我认为删除“发布分支”并使它们成为标签是一个很好的做法，因为这就是标签的目的。
这并不能真正解决问题，尽管它可能会防止更多此类事故，因为你永远不应该在标签中工作。 我同意 brendin 的观点，如果仍然发生，请恢复这些更改，并踢掉开发人员:-)
I think it would be a good practice to remove the 'release branches' and make them a tag instead, as that's the purpose of a tag.
That doesn't really solve the problem, though it might prevent more of those accidents, since you should never work in a tag. And I agree with brendin, if it still happens, revert those changes, and kick the developer :-)
为什么使用分支作为标签？ 我建议：
话虽这么说，并假设您的存储库层次结构布局如下：
尽管 SVN 书籍反对以这种方式进行粒度控制，但您也可以使用 svn_access_file 来防止提交分支上的任何内容？ 例如：
如果您希望开发人员能够创建分支，那么您必须分别深入到每个分支（这又回到了 SVN 书籍建议反对该方法的整个前提）。
Why are you using branches as tags? I would suggest:
That being said, and assuming that you have your repository hierarchy laid-out as:
Although the SVN Book speaks against granular control in this manner, you may also use
svn_access_fileto prevent commits to anything on branches? For example:If you want developers to be able to create branches, then you'll have to descend into each branch individually (which gets back to the whole premise of the SVN Book advising against the method in the first place).