修改外部变量的SVN提交后挂钩

Question

我们有一个Subversion设置，它相当广泛地使用了svn: external (一个项目中超过5个外部引用，虽然大多数都在同一个存储库中，但有一两个位于不同的存储库中，但仍然在同一服务器上)。目前，svn:externals属性的设置方式是拥有所引用项目的完整URL (即“https://[server]:[port]/svn/Repository1/Projects/...”)

最近，我使用svnsync设置了一个SVN镜像，它将我们的存储库备份到外部异地设备。我们需要从远程站点的那些镜像存储库执行只读签出的能力，这似乎在大多数情况下都工作得很好，除了当它试图拉出外部时，它仍然引用我们本地的站点服务器。

我不确定这是否是最好的方法，但我想在远程位置设置某种post-commit挂钩，它将修改svn:externals的属性，并将本地服务器的主机名替换为远程服务器的主机名。这个钩子将在svnsync每次提交后运行。

理想情况下，我们希望避免修改主存储库中的svn: our属性，使其不包含服务器名称。

以前有没有人遇到过这个问题？做这件事最好的方法是什么？

Answer 1

您必须了解svn:externals是文件的一个属性，修改它们需要提交。如果您有一个镜像，并且您修改了svn:external，那么您正在创建一个新的远程版本并破坏您的镜像。修订将不再对齐。

尽管svn:externals在当时看起来是一个很好的想法，但它在项目中可能非常糟糕。想象一个这样的项目：

http://vegibank.com/svn/trunk/project1

我在这个目录上有一个svn:external

$ svn pset svn:external "^/trunk/project2/foo foo" .

我这样做是因为foo目录是多个项目的共享文件集。

现在，我为project1创建了一个标记：

$ svn cp http://vegibank.com/svn/trunk/project1 http://vegibank.com/svn/tags/1.2.3

看起来不错--除了project1/foo目录没有标记。它链接到 project2/foo.的主干

我对标签的假设是标签永远不会改变，但这不是真的。在主干上的project2/foo上的工作仍在进行中，这改变了我的标记所代表的内容。如果我在1.2.3版中有一个bug，我决定检查我的标签，看看可能是什么问题，我不一定会得到我在project1/foo中发布的东西--我会从主干中得到最新的。

处理这个问题的更好方法是创建一个发布存储库，将各种项目之间通用的代码构建为某种预编译的工件，并让您的项目依赖于该版本的工件。它最终与依赖于特定版本的libz.so的C程序或依赖于org.apache.commons.httpd 1.6版的Java项目没有什么不同。

这将消除svn:externals的使用并简化您的镜像。您可以镜像发布存储库以及源代码库。

如果你坚持使用svn:external，不要使用完整的网址。相反，请使用相对URL。

例如，如果您在上面设置了` `svn:external，而不是这样：

$ svn pset svn:external "^/trunk/project2/foo foo" .

为此，请执行以下操作：

$ svn pset svn:external "../project2/foo foo" .   #property on ^/trunk/project1

现在，如果我创建一个这样的标签：

$ svn cp http://vegibank.com/svn/trunk http://vegibank.com/svn/tags/1.2.3

我同时标记了project1和project2。现在，我的svn:external引用http://vegibank.com/svn/tags/1.2.3/project2/foo。

您需要的是一种以这种方式强制执行svn:externals的方法，并且您可以使用预提交挂钩来拒绝任何具有引用trunk或branches目录的svn:external集的提交，而无需指定实际的修订。

Answer 2

您运行的是什么版本的svn？如果您是当前版本，则可以避免将主机名放入svn:externals read the redbook中，具体请查看使用/启动外部

你应该强烈地考虑走出svn:externals的泥潭...尤其是如果链接指向相同的存储库...你的分支和标记更难了。我见过很多svn实现和svn:外部变量通常很难闻。

此外，作为一般规则，我认为拥有一个提交后钩子来改变开发人员的意图是次优的。不过，在这种情况下，您可能会很好。