svn - svn :externals 的最佳实践使用

Question

我们来看三个案例:

这个说法很好。 999是一个 Hook 。这就是所谓的“旧格式”:

foo -r999 http://myrepo/foo

或者，也可以像这样指定 Hook (以“新格式”)，也很好:

http://myrepo/foo@999 foo

但这是“新格式”中的一个复杂问题:-r999可以放在前面，它的意思完全从一个钉子变成了一个“操作版本”。根据 SVN Book，实际 Hook 变为 HEAD(即不再具有确定性) :

-r999 http://myrepo/foo foo

这就是为什么我认为这种格式可能是一个非常糟糕的主意:如果在 rev 999 之后将“bar”重命名为“foo”，实际上会 check out 哪些内容？重命名的版本，bar@999。这真的有用吗？然后，另一个重命名发生，将“baz”命名为“foo”。现在用户将检查 baz@999。因此，随着时间的推移，用户将永远无法确定 999 指的是相同的代码。

#3 是一个等待引起麻烦的漏洞吗？是否应该用亮红旗警告用户以避免使用 #3 的格式？或者它实际上有用，尽管它具有不确定性？这几乎太容易被误解和出错，因此似乎需要指定最佳实践。

来自 SVN Book ，如果你真的深入研究它，它巧妙地提示用户要小心:

be careful to avoid naively relocating the -rNNN portion of the definition—the older format uses that revision as a peg revision, but the newer format uses it as an operative revision (with a peg revision of HEAD unless otherwise specified; see the section called “Peg and Operative Revisions” for a full explanation of the distinction here).

Answer 1

使用外挂？最佳实践？

这很容易! 不要这样做!
svn:externals是那些看起来是个好主意的事情之一，但最终导致了各种各样的问题。我发现有比使用 svn:externals 更好的方法来做到这一点。 .例如，您可以使用 Maven 或 Ivy 为您进行依赖管理。

但是，如果我必须使用 svn:externals ，我将使用标签而不是绝对修订。这在较新版本的 Subversion 中效果更好，而且我通常不必担心使用特定的修订版，但是随着文件的重命名和移动，文件的 URL 都会发生变化。对我来说，标签是不可变的，一旦创建，它们就永远不会改变。

这也鼓励您考虑您的 svn:externals作为完全独立的项目。例如，您可以谈论 Foundation 的 4.3 版。您的 svn:externals命令看起来像这样:

$ svn propset svn:externals `^/tags/4.3/foundation foundation` .

注意我没有将 URL 方案放在标签或服务器名称中。如果外部与项目在同一个存储库中，我几乎总是使用相对路径。想象一下，如果你习惯使用 http:// ，然后您转而使用 https:// ，或者您的 Subversion 存储库机器的名称发生变化。外部仍然可以使用这个方案，但如果我这样做了，就会中断:

$ svn propset svn:externals "http://server.com/svn//tags/foundation foundation" .

我是一个可悲的骗子

我目前在一个我没有做我上面提到的项目的项目中工作。我的 svn:externals 不使用标签，我们所有的项目都必须有它们。

在这家公司，他们在 jar 依赖管理方面遇到了一个可怕的问题。他们生产了大约十几个用于多个项目的基本 jar 。这些项目中的每一个都有不同的方式来指定这些 jars

为了解决这个问题，我建立了一个名为 ivy.dir 的特殊 Ivy 项目。 .开发人员被告知使用以下命令将此项目合并到他们当前的项目中:

$ svn propset svn:externals "../ivy.dir ivy.dir" .

内ivy.dir是将您的项目集成到 Ivy 的完整设置。 Ivy 已预先配置为使用我们新的企业 Maven 存储库。我们所有的各种构建工具都在这里。

这种方法使将 Ivy 和良好的依赖管理集成到我们的项目中变得轻而易举。你只是<import> ivy.dir/ivy.tasks.xml文件到您当前的 build.xml ，并使用 <ivy:cachepath>创建您的类路径。一个好的、结构良好的 build.xml只需稍加修改即可运行。

我什至创建了一个特殊的 <jar.macro>宏定义。它几乎 100% 兼容 <jar>宏，但它会自动创建一个 pom.xml来自 ivy.xml 的文件并将其嵌入到构建的 Jar 中(还将包括 Jenkins 项目名称、构建日期和构建编号。)

通过使用相对 URL，我可以轻松地对所有内容进行分支或标记(并且 ivy.dir 项目也被标记)。

这是一种奇怪的使用方式 svn:externals ，但它使我们能够摆脱之前许多项目使用的可怕使用svn:externals拉入存储在存储库中的 jar 。