另一个 svn:externals 中的 svn:externals 问题

Question

我在签出我的 svn 存储库中的标记版本时遇到了一些麻烦，很可能是因为内部的 'svn:externals' 没有引用正确的修订版。让我们考虑简化的情况：

我有第一个 svn 存储库，它在 XXX1 修订版中看起来像这样：

Repo1 (@ Rev XXX1)
  tags
    ...
  trunk
    Folder1
      ExternalRefToFolder2 (svn:externals '../Folder2')
    Folder2
      SomeFile1.txt
      SomeFile2.txt

并且已经重构为（在头部修订时）：

Repo1 (@ HEAD1)
  tags
    ...
  trunk
    Folder1
      SomeFile1.txt
      SomeFile2.txt

IE：无论好坏，对 Folder2 的外部引用已被删除并替换为修订版 XXX1 和 HEAD1 之间的文件副本。

我在同一台服务器上还有第二个存储库，如下所示：

Repo2 (@ HEAD2) 
  tags
    1.0.0
      ExternalToRepo1 (svn:externals -rXXX1 ^/../Repo1/trunk)
  trunk
    ExternalToRepo1 (svn:externals ^/../Repo1/trunk)

IE：同样，无论好坏，第二个存储库使用外部引用引用第一个存储库（trunk 中的修订版HEAD1 和标记版本中的修订版XXX1，以便将所有内容冻结在正确的位置修订）。

问题

• 当我签出trunk 的Repo2 时，我没有问题。即Repo1 与其单个Folder1 签出。

• 当我查看Repo2 的标签1.0.0 时，svn 抱怨它在HEAD1 修订版中找不到http://server//Repo1//trunk//Folder2。

因此，即使标签1.0.0 在其正确的XXX1 修订版中引用Repo1/trunk，这一切看起来也是如此； inner 外部svn:externals '../Folder2' 被解释为基于HEAD1（而不是我预期的修订版XXX1）。

这种行为是否正常，我该如何解决这个问题？

注意：我拥有的 Svn 版本是 1.7.8 (r1419671) 编译于 2012 年 12 月 12 日

编辑

重现此问题的另一种方法是签出或简单地浏览Repo1 修订版XXX1。 svn:externals '../Folder2' 将仍然与 HEAD1 相关，所以猜测没有太多解决方案。

Answer 1

乍一看它看起来有点奇怪，但你会发现它按预期工作。

SVN 为特定的提交集分配修订号，该提交集不仅可以包含更改，还可以包含通过 svn 副本创建的目录、文件、属性和链接（所谓的标签或分支）的添加或删除。 SVN 并没有真正复制来自文件系统的目录，而是将其内容链接到一个新目录。当所有链接（原始目录和复制目录）都被删除时，内容会在 SVN 历史的深处“暂停”（但实际上并未删除）。您可以随时更新到最后一个修订版已包含该目录的最后链接内容。

外部内容就像您可以设置到外部存储库的链接，但与始终由同一存储库维护的链接相反，外部内容实际上不能“暂停”，因为它是从存储库的另一端控制的包含外部的内容。换句话说，存储库包含一个外部链接，并且存储库存储了一个内容，因为它可以维护完全不同的地址并位于不同的机器上。

这就是为什么您必须为外部设置正确的修订号时会发生什么样的错误，否则外部链接将采用最后一个，即 HEAD。当内容已经不存在时，您的 ExternalRefToFolder2 会进行头部修订。要么明确设置外部修订版，要么使用 svn copy。

但请记住，svn copy 创建链接但有它自己的内容历史。这意味着对链接到修订的 Folder2 的所有提交都不会通过链接到修订的 ExternalRefToFolder2/Folder2 更改内容，反之亦然。

因此，嵌套链接和外部链接的工作方式相同。这只是另一个级别的参考。您必须为所有外部设置（并提交相关属性）特定修订，以便从根获取确切的目录树结构/内容。

Answer 2

使用svn:externals 作为穷人的依赖管理或代码重复避免方案是你的麻烦之源。嵌套它们并不是双重的坏事，它是乘法的。 我推荐这个excellent long answer about the badness with externals

使用svn:externals 处理内部事务永远不会有很好的结果，但是如果你继续使用它们，你可以通过以下方式减轻痛苦：

1. 听从red book 的建议，切勿对头部进行外部拉动：

您应该认真考虑在所有外部定义中使用明确的修订号。这样做意味着您可以决定何时拉取外部信息的不同快照，以及拉取哪个快照。除了避免对您可能无法控制的第三方存储库进行更改之外，使用明确的修订号还意味着当您将工作副本回溯到以前的修订时，您的外部定义也将恢复到它们的外观在之前的修订版中，这反过来意味着外部工作副本将被更新以匹配它们在您的存储库处于之前的修订版时回顾的方式。对于软件项目，这可能是复杂代码库旧快照构建成功和失败之间的区别。

1. 如果您不执行上述操作，请使用svncopy.pl 创建您的标签。当您创建标签时，它会将您的外部版本“固定”到它们的任何位置。

您没有提到为什么您有多个存储库 - 您是否有可能从整合中受益？
您没有提到您使用的语言/工具。我很确定有更好的方法可以满足您的要求。例如，如果它是一个带有一些库的 java 应用程序，您通过外部引入 - 如果您单独构建库并使用类似 maven 的物质发布它们，然后在构建应用程序时解析它们，您会更开心。