颠覆加载失败，并显示“无此修订”

我正在尝试学习如何迁移Subversion存储库，并且遇到了对我来说没有意义的问题。我曾经svndumpfilter拆分过一个子项目，并删除了一些路径前缀。现在可以正确导入数百个提交，但是随后出现以下错误：

<<< Started new transaction, based on original revision 19190
     * editing path : branches/features/DynamicSource ... done.
     * editing path : branches/features/DynamicSource/src/build.properties ... done.
     * editing path : branches/features/DynamicSource/src/client/default.htm ...done.
     * editing path : branches/features/DynamicSource/src/client/js/AdHocController.js ... done.
     * editing path : branches/features/DynamicSource/src/client/js/Report.js ... done.
svnadmin: E160006: No such revision 19098
     * adding path : branches/features/DynamicSource/src/client/js/Enums.js ...

好的，所以我进入转储文件以查看修订版19190和19098。首先，修订版19098 确实存在于转储文件中，并且可以顺利导入。修订19190是合并。在19190年内，这是最后一个文件的信息，这似乎是导致此问题的原因：

Node-copyfrom-rev: 19100
Node-copyfrom-path: trunk/src/client/js/Enums.js
Text-copy-source-md5: 2db7f8d9c0ba4750d88ce0722731aad6
Node-path: branches/features/DynamicSource/src/client/js/Enums.js
Node-action: add
Text-copy-source-sha1: 8f930509f8dbc17c5e82cd40aa5a76454d3d812c
Node-kind: file
Content-length: 0

令人困惑的是，此过滤文件中不存在版本19100。但是错误不是指19100，而是指19098！

我该怎么做才能加载该文件？

谢谢！

svn

— 哈兰
source

如果复杂的操作（“转储和过滤器”后跟“导入”）失败，请先尝试更简单的操作（“转储”，然后再“导入”）。我只迁移了整个回购协议，这很容易做到。

— 德克·埃德比布特

谢谢，德克。不过，我们确实必须拆分此存储库。

— 哈兰

也许做“转储，导入。手动减少，再转储。导入第二次转储。” ？

— 德克·埃德比布特

除非我缺少任何东西，否则我认为SVN不会那样工作。您必须减少使用转储文件和svndumpfilter。我们确实希望尽可能保留历史。

— 哈兰

为什么不迁移到git或mercurial，并在同一步骤中删除旧版SVN？

— vonbrand 2014年

Answers:

我已经做了很多次这种拆分。我认为这取决于您如何使用过滤器以及之后对转储文件执行的处理。就个人而言，我还必须更改项目路径旁边的svn用户，并重新编号修订版本。只是您可以看到可以做什么，这是我脚本的相关部分。

grp=$cust_group
usr=$cust_customer
svndumpfilter include $grp/$usr --drop-empty-revs --renumber-revs  <$repo_dump > $repo_dump.$usr
sed -e "s/Node-path: $grp\/$usr/Node-path: /" <$repo_dump.$usr >$repo_dump.$usr.fixed1
sed -e "s/Node-copyfrom-path: $grp\/$usr/Node-copyfrom-path: /" <$repo_dump.$usr.fixed1 >$repo_dump.$usr.fixed2
sed -e "/Node-path: /{ N; N; N; N; N; N; s/Node-path: \nNode-action: add\nNode-kind: dir\nProp-content-length: 10\nContent-length: 10\n\nPROPS-END//}" <$repo_dump.$usr.fixed2 >$repo_dump.$usr.fixed3
sed -e "/svn:author/{ N; N; s/svn:author\n.*\n$svn_usr_from/svn:author\nV $svn_usr_len\n$svn_usr_to/}" <$repo_dump.$usr.fixed3 >$repo_dump.$usr.fixed4
svnadmin load $repo_dir/$cust_group/$cust_customer --ignore-uuid < $repo_dump.$usr.fixed4

chown svn:svn -R $repo_dir/$cust_group/$cust_customer
#chown apache $repo_dir/$cust_group/$cust_customer/db/txn-current
#chown apache $repo_dir/$cust_group/$cust_customer/db/current
# apache is in svn group so the above 2 are not needed
chmod -R g+rw $repo_dir/$cust_group/$cust_customer

发生的情况是，首先，我过滤出我需要的内容，出于明显的原因，我删除了空的修订，然后重新编号。这给出了很好的有序修订。然后，我删除项目的根路径，在我的情况下，该路径以组/客户的形式出现，因为在新仓库中没有任何意义（相反，仓库本身是磁盘上的组/客户）-这是前两个sed的

接下来，我删除了未命名目录的导入，其中一个是由上述2个sed生成的，用于组dir，然后一个用于添加组/客户的dir。

最后，我诱使作者将其更改为新的。这也有些棘手，因为它需要更新属性定义的长度。

然后我将其加载并修复文件系统权限。请注意2个注释的阿帕奇小菜，在某些情况下您将需要它。我最终将apache添加到svn group。

现在，我再也没有在SVN存储库中合并过，所以我不需要为拆分而处理它们。在您的情况下，我可以想象发生的情况是未导入源修订版本路径，这就是即使错误抱怨修订版本本身也找不到它的原因。svn导入文件中的经验法则是，在引用某个点之前，必须先导入任何内容。因此，即使您需要它，您也可能已经过滤掉了不应该删除的内容，或者没有正确更新转储文件以反映所做的任何其他更改。

如果您提供了原始存储库的相关结构（包括合并的源路径）以及带有参数的调用，那么我可能可以给您打电话给您遗漏的内容。我的钱来自合并的来源。

— 轻松地
source

我使用了一个很棒的工具svndumpsanitizer。问题在于，Subversion存储库的结构过于复杂。当svndumpfilter的版本为10时，它无法知道用户是否要丢弃的节点是否将移动到他希望保留在版本113中的位置。因此，它唯一可以做的-丢弃该节点，而在修订版113中，由于它已经丢弃了原来需要的数据，因此无法使用。

Svndumpsanitizer以不同的方式工作。它扫描节点几次，以发现实际上应保留哪些节点。在确定要保留的节点之后，它仅将这些节点写入输出文件。最后，如果有必要，它会添加一个提交，该提交将删除必须保留的所有不需要的节点，以免破坏存储库。

— ALex_hha
source