我正在为我的公司调查svn externals，看起来它对我们来说是一个很好的功能。我们有几个产品经常引用共享组件，但有一个坏习惯，即落后于旧版本甚至不同的分支代码库有时。
我已经读了很多关于他们现在如何工作的内容，我想我理解这个概念。我不是100％肯定的是多个存储库的不同版本如何链接在一起。
假设我有一个产品和一个库。产品是针对库构建的，因此其repo具有链接到库源的svn：externals属性。在svn：externals定义中没有特定版本的情况下，当我查看产品的HEAD时，我也得到了HEAD of Library。
多年来，我构建了多个版本的Product，每次都引用了最新版本的Library。有一天，我必须通过手动选择正确的版本返回并查看产品版本1。当我这样做时，我会得到哪个版本的库，HEAD还是我第一次构建它时使用的版本？
希望我是一名优秀的开发人员，并记得标记我发布的每个版本的产品。当我将我的标签'Product-1-0-0'应用到存储库时，库存储库的正确版本是否也被标记了？如果我稍后根据标签'Product-1-0-0'查看产品，是否可以使用它来检查库的正确版本？
答案 0 :(得分：6)
svn:externals需要注意的是，如果您需要除trunk之外的其他内容，则需要明确指定修订版。 Google "pinning svn:externals"了解详情。如果您使用相当现代的版本，1.5或更新的IIRC，那么至少支持相对的外部。旧版本（如我目前使用的版本）要求我们使用-rNNNNN属性{em>每个该死的文件夹，使用svn:externals选项明确地修改版本。
我们最终使用来自tigris.org的名为svncopy.pl的perl脚本的修改来完成所有分支和标记。这并不是那么糟糕，但我希望在我们决定大量使用它们之前，我们已经知道它有多少工作。
答案 1 :(得分：5)
您可以使用date specifiers确保在更新时获得相应的修订。
我们已经为一个运行PC-Lint的工具做过了;我们喜欢在每个版本上运行它，以便我们可以区分结果。
它的实施有点令人讨厌 - 我们：
svnversion）svn info）svn log）svn update -r {sometimestamp}）（复杂性值得Rube Goldberg，不是吗？对任何能提出更好解决方案的人都表示赞赏和不懈的感激。）
你可能也对我刚刚发现的Peg and Operative Revisions上的svn书的部分感兴趣 - 这似乎是一个相对较新的补充。
答案 2 :(得分：2)
你应该阅读依赖管理器 - 我不确定你的平台是什么，但常春藤和maven以更清洁的方式解决了这个问题。
svn：exversion在subversion中没有版本化。如果有人更改了您的某个外部的修订或标记，则无法知道更改之前的内容。
答案 3 :(得分：1)
是的，假设您在外部提供明确的修订号，正如docs中所建议的那样。否则，它将使用引用的外部的HEAD修订版。
请注意1.6中基于文件的svn：externals。它们看起来非常有用，但我今天刚刚点击this bug :(
答案 4 :(得分：0)