![保留 Subversion 存储库的一部分,但中间发生路径更改](https://linux22.com/image/488307/%E4%BF%9D%E7%95%99%20Subversion%20%E5%AD%98%E5%82%A8%E5%BA%93%E7%9A%84%E4%B8%80%E9%83%A8%E5%88%86%EF%BC%8C%E4%BD%86%E4%B8%AD%E9%97%B4%E5%8F%91%E7%94%9F%E8%B7%AF%E5%BE%84%E6%9B%B4%E6%94%B9.png)
我有一个 Subversion 存储库,其中的目录曾经被移动过。我想只向某人发送存储库的一部分,其中包括此目录。
我相信我已经阅读并理解手册。
我尝试过的:
svnadmin dump /home/Subversion-Repository | \ svndumpfilter 包括新名称/新名称/foo/bar/旧名称> something.svn svnadmin 创建/new/repos # 创建目录 foo/bar 和 new-name svnadmin 加载 /new/repos < something.svn
但它失败了:
<<< 根据原始修订 5944 开始新交易 svnadmin:未找到文件:事务‘5944-4l4’,路径‘new-name/myfile’ * 编辑路径:new-name/myfile...
令我惊讶的是,在完整转储中(没有经过 svndumpfilter),有一个修订版在新的位置添加了文件:
节点路径:新名称 节点类型:dir 节点操作:添加 道具内容长度:10 内容长度:10
但 svndumpfilter 不会保留它。因此,第一个提到新名称下文件的修订是“Node-action: change”,而不是“Node-action: add”,并且失败。为什么?
可以随意重现问题的 Unix shell 脚本是可用的。
[我在 Subversion 邮件列表上提出了这个问题,但是该消息没有被分发,可能是被过于热心的垃圾邮件过滤器吞掉了。]
更新:我测试了 Insyte 的建议。svndumpfilter2 和 svndumpfilter3 都失败了。它们甚至都不检查参数,你可以给它们一个不存在的存储库,它们不会抱怨。
使用 svndumpfilter2,修改我的脚本使用${SVNDUMPFILTER2} ${REPOS} other/new-name/bar foo/old-name/bar > ${DUMP}
:
<<< 根据原修订版本 7 开始新交易 svnadmin:未找到文件:事务‘8-8’,路径‘other/new-name/bar/myfile’ * 编辑路径:other/new-name/bar/myfile...
使用 svndumpfilter3,修改我的脚本使用
${SVNDUMPFILTER3} --untangle=${REPOS} other/new-name/bar foo/old-name/bar > ${DUMP}
:
<<< 根据原修订版本 7 开始新交易 svnadmin:未找到文件:事务‘8-8’,路径‘/other/new-name/bar/myfile’ * 编辑路径:other/new-name/bar/myfile...
答案1
我相信您遇到的是该svndumpfilter: Invalid copy source path
问题的变体。当 svndumpfilter 包含的目录/文件之一最初是从树的一部分复制(或,在您的情况下是移动)时,就会发生此问题不是被包括在内。最初的解决方案是 Simon Tatham 的
svndumpfilter2但他的 svn 服务器目前似乎已关闭。
此处提供稍微修改过的版本: http://www.dehora.net/hg/tools/raw-file/tip/svn/svndumpfilter2
这里有另一种变体: http://furius.ca/pubcode/pub/conf/bin/svndumpfilter3.html
还有一个: http://www.undersea.com/~nmb/svndumpfilter4
这里有对 svndumpfilter4 的解释(来自 archive.org - 不幸的是原文已经无法访问): http://replay.waybackmachine.org/20080827213200/http://www.undersea.com/~nburrell/blog/node/81
这些变体足够智能,可以使用 svnlook 来检索必要的源材料,即使它位于树的包含部分之外。
答案2
好的,我现在有了一个可行的解决方案,并在实际存储库上进行了测试。这个想法是只转储重命名之前的修订(不包括),然后转储重命名之后的修订(使用选项--incremental
)。然后,我重新加载第一个转储,在新存储库中重命名,然后重新加载第二个转储。它似乎正常工作。
我制造了一个我的脚本的修改版本其中显示了详细的步骤。
如果我理解正确的话,最初的问题是重命名发生在树中比我想要保留的目录更高的级别,因此 svndumpfilter 没有保留它。因此,重命名后对文件的操作失败,因为转储中的节点是 类型,而新位置change
没有 类型的节点。add
答案3
你也可以尝试转储消毒剂。它可以处理文件/目录被移动的问题,而无需手动执行。我们使用这种方法将旧存储库的一部分设置为新存储库的基线。