SVN：最小化将项目移动到自己的仓库所需的转储

Posted 2023-02-23

【中文标题】SVN：最小化将项目移动到自己的仓库所需的转储

【英文标题】：SVN: Minimize the dump needed to move project into its own repo

【发布时间】：2014-08-27 22:00:44

【问题描述】：

我最初的问题如下。从那以后，我尝试了一些方法，看看能否让它发挥作用。

我有一个看起来像这样的小 shell 脚本：

svnadmin dump -r108917 ./repo \
    | svndumpfilter include /KeyManagement \
          --drop-empty-revs \
          --skip-missing-merge-sources \ 
          --renumber-revs > km.svndump \

while read rev
do
    svnadmin dump -r$rev --incremental ./repo \
        | svndumpfilter include /KeyManagement \
             --drop-empty-revs \
             --skip-missing-merge-sources \
             --renumber-revs >> km.svndump
done << km.revs.txt

km.revs.txt 是一个文本文件，其中仅包含包含对 /KeyManagment 项目的更改的修订。

当我第一次这样做时，我以为我会在之后进行过滤。然而，在转储的第一个修订版中，km.svndump 的大小增长到超过 68 GB。哎呀。在第二次尝试中，我通过svndumpfilter 过滤项目。

这运行了很长一段时间（我nohup'd 并只是不时检查它）。完成后，我收到了km.svndump，它显示了 UUID、第一个修订版和 内存不足 错误。显然，我的脚本没有通过要转储的第一个修订版。

任何想法如何继续？

---

我们有一个带有 特殊 项目的存储库，该项目与存储库的其余部分确实不兼容。 LDAP 组Development 中的任何用户都可以看到整个存储库。但是，一个项目包含我们只希望从事该项目的人看到的信息。 （我们的密钥管理项目）。 Repo 布局如下所示：

/trunk - 其余部分的主干 /branches - 其余部分的分支 /tags - 其余 repo 的标签 /KeyManagement - 特殊密钥管理项目。

为了防止窥探，我们使用 svn_acces 文件来指定可以看到此内容的用户。这在维护中引起了很多问题，我只想让KeyManagement 成为一个具有自己的 LDAP 访问组的单独存储库。 （我们已经有多个具有自己的 LDAP 组的存储库）。

问题是我们的 repo 中有超过 175,000 个修订，其中只有 124 个修订与 KeyManagement 项目有关。转出所有 175,000 个修订版大约需要 30 多个小时。如果我可以直接转储出我需要的修订，我可以在几个小时内完成整个转储。

另一个问题是这样的：

$ svn log -r108917:108918 -v $REPO
------------------------------------------------------------------------
r108917 | svnadmin | 2011-03-23 00:46:04 -0500 (Wed, 23 Mar 2011) | 1 line
Changed paths:
A /KeyManagement

New folder KeyManagement
------------------------------------------------------------------------
r108918 | svnadmin | 2011-03-23 00:47:18 -0500 (Wed, 23 Mar 2011) | 1 line
Changed paths:
A /KeyManagement/trunk (from /trunk/KeyManagement:108917)
D /trunk/KeyManagement

Move the KeyManagement
------------------------------------------------------------------------

显然，KeyManagement 曾经也在/trunk 之下。我之前使用svndumpfilter 进行转储和加载的经验是，我必须同时转储和加载/KeyManagement 和/trunk/KeyMangement。说实话，我不关心/trunk/KeyManagement，因为应用程序完全重做，没有人关心代码。

我了解转储的第一个修订版是完整的修订版。我可以做这样的事情吗：

$ svnadmin dump -r108917:108918 old_repo > dump_file
$ svnadmin dump -r108103 --incremental old_repo >> dump_file #Revision with KeyManagement
$ svnadmin dump -r107429 --incremental old_repo >> dump_file #Revision with KeyManagement
...

$ svnadmin load --parent-dir new_repo < dump_file

然后转储与 KeyManagement 相关的修订。我不关心/trunk 下的版本。从那时起，该项目已经完全修改。我知道修订版，我可以很容易地编写一个 shell 脚本来做到这一点。与 KeyManagement 相关的修订没有任何其他项目与之纠缠。

我只是不想花 40 多个小时来做​​这件事。

【问题讨论】：

关于谵妄的权利：你试过svnrdump dump URL/Of/KeyManagement吗？

我没有尝试svnrdump。事实上，我在我的 Mac 上找不到它，svn、svnadmin、svnlook、svndumpfilter、svnversion、svnsync 和 svnserve 所在的位置。不，svnrdump 在 /Applications/Xcode.app/Contents/Developer/usr/bin 下，以及所有其他 Subversion 命令的相同 1.7.10 版本。我会将它们全部链接到/usr/local/bin，它位于/usr/bin 之前的路径中。

我之前没用过svnrdump。这是一个相当新的工具，看起来它的工作方式与svndump 有点不同。看起来 svnrdump 会同时进行过滤和转储。

【参考方案1】：

我终于使用了 svnrdump。我不得不转储所有的修订，但它允许我指定我只想要 /KeyManagement。对于svndump 和svndumpfilter，我必须指定/KeyManagement 和 /trunk/KeyManagment，因为这是原始项目所在的位置。

很遗憾，您不能在 svnrdump 上使用 svndumpfilter，而且由于报告了所有修订，因此我无法重新编号并忽略空的。

svnrdump 仍然允许我仅捕获一个目录，即使我无法更改其位置或跳过空修订并重新编号。

【讨论】：

将单个目录加载到单独的存储库后，您可以使用svndump 再次转储它以过滤空修订，然后再将其加载到最终目的地。也就是说，假设该单个目录的初始修订版要小一些。另外，不要忘记更改新副本上的 UUID，因为我发现以后可能会咬你...

不。没用。我实际上是这样做的。 svndumpfilter 没有过滤掉任何东西，因为所有事务要么只是提交消息，要么属于 /KeyMangement 项目。然后，svnadmin load 没有重新编号提交，因为没有空提交。如果svnrdump 和svndump 使用相同的格式，或者svndumpfilter 可以处理type 3 repo 转储，那就太好了。