保持一个Subversion版本库的一部分,但是中间有一个path变化

我有一个目录被移动一次的Subversion版本库。 我想发送给只有一部分存储库,其中包括这个目录的人。

我相信我已经阅读并理解了这本手册 。

我试过的:

 svnadmin dump / home / Subversion-Repository |  \
    svndumpfilter包括new-name / new-name / foo / bar / old-name> something.svn

 svnadmin创build/新/回购
 #创build目录foo / bar和新名称
 svnadmin load / new / repos <something.svn

但是它失败了:

 <<<根据原始修订版5944开始新的交易
 svnadmin:找不到文件:事务'5944-4l4',path'new-name / myfile'
      *编辑path:新名称/ myfile ...

令我惊讶的是,在完整的转储(没有经过svndumpfilter),有一个修改,在新的地方添加文件:

节点path:新名称
节点类:dir
节点操作:添加
 Prop-content-length:10
内容长度:10

但svndumpfilter不保留它。 因此,第一次提到新名称的文件是“Node-action:change”而不是“Node-action:add”,并且失败。 为什么?

Unix shell脚本可以随意重现问题。

[我在Subversion邮件列表上问了这个问题,但是这个消息没有被分发,可能被过分热心的垃圾邮件filter所占用。]

更新:我testing了Insyte的build议。 svndumpfilter2和svndumpfilter3都失败。 两者甚至不检查参数,你可以给他们一个不存在的存储库,他们不会抱怨。

使用svndumpfilter2,修改脚本使用${SVNDUMPFILTER2} ${REPOS} other/new-name/bar foo/old-name/bar > ${DUMP}

 <<<根据原始修订版本7开始新的交易
 svnadmin:找不到文件:事务'8-8',path'other / new-name / bar / myfile'
      *编辑path:other / new-name / bar / myfile ...

使用svndumpfilter3,修改我的脚本使用${SVNDUMPFILTER3} --untangle=${REPOS} other/new-name/bar foo/old-name/bar > ${DUMP}

 <<<根据原始修订版本7开始新的交易
 svnadmin:找不到文件:事务'8-8',path'/ other / new-name / bar / myfile'
      *编辑path:other / new-name / bar / myfile ...

我相信你遇到了一个svndumpfilter: Invalid copy source path的变种svndumpfilter: Invalid copy source path问题。 当svndumpfilter包含的目录/文件之一最初被复制(或者,在你的情况下,移动) 包含的树的一部分时,会发生此问题。 最初的解决scheme是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来检索必要的源代码,即使它不在树的包含部分。

好吧,我现在有一个解决scheme,在真实的存储库上testing。 这个想法是只转储修改直到(不包括)重命名,然后修改它(使用--incremental选项)。 然后,我重新加载第一个转储,我在新的存储库中进行重命名,然后重新加载第二个转储。 它似乎工作正常。

我做了一个我的脚本的修改版本 ,显示详细的步骤。

如果我理解正确,最初的问题是重命名发生在树的更高层次比我想保留的目录,所以不被svndumpfilter保存。 因此,重命名后的文件操作失败,因为转储中的节点typeschange并且没有为新位置addtypes的节点。

你也可以尝试一下dumpsanitizer 。 它处理文件/目录已被移动的问题,而不必手动完成。 我们使用这种方法将旧版本库的一部分设置为新版本库的基准。