除了从分支合并之外，如何锁定SVN中继？

Question

我想阻止开发人员直接在主干上工作。

我的目标是强制所有开发人员离开主干并在自己的分支上工作，直到CI测试被清除。然后，他们必须从主干合并到他们的分支（以获取最新的更改），在合并回主干之前运行并通过测试。

这种SVN用法有什么规则吗？

Answer 1

限制中继提交到机器人。该机器人可以进行无冲突合并并提交到trunk。我做到了那一点;它被称为mergebot（MIT许可）。它是一个守护进程和一个Trac插件，提供了一种分支每张票的方法。文档很薄，在极端情况下存在问题，但它主要是有效的。

Answer 2

要仅允许合并到主干，您可以使用预提交挂钩尝试区分合并与普通提交并拒绝后者。您可以通过检查是否更改任何路径上的“svn：mergeinfo”属性来判断提交是否为合并。 This mailing list thread有两个检查mergeinfo的钩子示例。这些示例实际上是尝试在特定路径上强制执行缺席，但如果您反转逻辑，则可以创建一个只接受合并的钩子。

开发人员仍有可能故意将其他更改与合并一起放入，并且无法检测到这种情况。这样一个预先提交的钩子可以温和地提醒开发者他们可能想要检查一个分支而不是主干，但只有在他们不是故意试图偷偷摸摸政策时它才有效。 / p>

一个更加铁定的解决方案是将对中继的写访问限制为您信任做正确事情的少数用户。然后，在每种情况下，这些用户都必须完成最后的“合并回主干”步骤。如果开发人员已经从主干合并到他们自己的分支，那么这个最后的合并回来是微不足道的，所以对你的可信用户来说不会是一个很大的负担。实际上，每当开发人员将其分支标记为“准备合并”时，最终的合并甚至可以通过自动化过程完成。我已经看到了这种自动合并过程的内部实现，但我不知道公开的任何内容。

Answer 3

你做不到。他们可以写入目录，也可以不写。

但是，您可能能够编写一个预提交钩子来检测他们是否正在尝试执行此操作并在中断情况下中止。

Answer 4

让开发人员在主干上工作会更简单，但是“直到他们开心”才会提交更改。您的开发人员可以使用其他开发人员提交的更改来更轻松地更新代码。

您描述的设置更适用于在合并更改之前必须获得经理或用户明确授权的开发人员。您还必须手动管理从一个开发人员到需要这些更改以进行更改的其他开发人员的分支更改。 （分支到分支合并）。

我拒绝访问我的组中的Cobol开发人员访问SVN中继。我通过编写自己的Eclipse插件来自动创建分支并执行合并回到主干。

Answer 5

我无论如何都不是SVN专家，Daniel的回答是有道理的，所以我可能需要SVN / WebDAV专家告诉我为什么这不起作用：

This page记录了各种SVN命令使用的WebDAV方法。您似乎可以通过拒绝用户使用{{1}的权限来“锁定”commit，rm，copy，mv和mkdir }} 方法。这仍然允许MKACTIVITY，diff，merge，checkout，ls等。

因此，您需要做的就是在Apache配置中，在与{trunk}目录对应的cat指令内设置<Limit>或<LimitExcept>指令。我没有对此进行测试，但它看起来像是：

<Location>

您应该能够将其嵌套在存储库的主<Location /repo/myproject/trunk> ... AuthType Digest AuthName "Repository Admins Only" AuthDigestProvider file AuthUserFile "E:/Sites/.htpasswd-admin" <Limit MKACTIVITY> Require valid-user </Limit> ... </Location> 指令中。这都是假设您使用HTTPS访问存储库。

Answer 6

您必须设置一个处理此情况的提交挂钩。但是我不确定你是否真的可以将一个提交到trunk从一个合并分离到trunk（可能基于svn：mergeinfo更改）...但是我建议将这个需求描述给开发人员而不是强制它......顺便说一下，必须编写和测试提交脚本的方式，如果你向开发人员解释这个，我认为并不是真正需要的。

Answer 7

使用SVN权限限制他们对/trunk的访问权限。允许他们阅读，但不允许写。分配一个可以写入/trunk的“架构师”角色。开发人员必须在分支准备就绪时向架构师报告，架构师将手动通过测试，然后合并到/trunk。