logo标签列表

SVN转Git迁移：不完整的历史记录

gitsvnmigration
7
我正在按照这篇答案迁移我的SVN存储库。 一切都进行得很顺利，除了最后我没有完整的历史记录。我可以追踪到问题源头是我做的一个“SVN move”。
这是我做的事情： 开始时，我的SVN存储库没有 文件夹。后来我引入它们，并将所有内容移动到trunk中（然后我创建了一个分支，这就是我决定引入新文件夹结构的原因）。
因此，在将SVN存储库迁移到git后，只有介绍新文件夹结构之后的历史记录可用。
我在一个非常简单的场景中重现了这个问题。
SVN中的历史记录： enter image description here git中的历史记录： enter image description here 包含SVN repo/git repo的zip文件： https://www.dropbox.com/s/ecy54st05qah4up/svn_git_problem.zip?dl=0 有没有办法解决这个问题？
我在使用链接下载仓库压缩文件时，经常会遇到很多弹窗和病毒错误提示。你能否将其发布到像dropbox.com这样没有弹窗和广告的网站上？ - Stan Kurdziel
2
抱歉，我的链接有问题。已完成翻译。 - OschtärEi
1个回答
3
当您指定--stdlayout时，git svn clone只会关注修改/ trunk、/ branches或/ tags路径下的svn提交-其他提交将被忽略。您仍然会得到一个有效的存储库副本，但是从r1到创建标准布局的历史记录将丢失，正如您所观察到的那样。由于您希望Git存储库在布局更改后理解主干，分支和标记，因此仍然需要--stdlayout，否则git clone将把所有分支合并成一个树，其中包括/ trunk / branches / tags，这不是您想要的。
如果您真的很关心预布局更改历史记录（而且如果这仅是一次性迁移，没有移动到Git后的SVN提交），则可以使用--stdlayout和不使用它两次运行git svn clone。 stdlayout版本将成为最终存储库，并且非stdlayout版本仅在迁移期间使用，以在重新组织的时间点下方钉住新布局之下的先前布局更改历史记录。这可以通过将所有重新组织后的提交cherry-pick到重新组织时存储库的快照上来完成。
一旦克隆了两个存储库，您会注意到在复制到新布局的时候，主干有一个公共树哈希。以下是一个示例（很抱歉没有使用您的库，因此哈希值有所不同）：
# git log --pretty=raw
commit 44f2f60e00117dfd51fd7d6431b697ec0ccc863d
tree 5cf62e006bb7b58171010fc0ffaba08ca97520da
parent d403c6ce0789cf584af9abb945bcfd88721e391e
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000

    change 4 after folder structure & branch

    git-svn-id: http://<redacted>/trunk@9 4ed80924-4846-11e4-8279-c5809b3f22e4

commit d403c6ce0789cf584af9abb945bcfd88721e391e
tree d6c0d6cf271be5146b26781ab9bd78736d86ace3
parent 0c5873eab204942ffe56370cc6e1d31e5372da13
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000

    changed: moved to new folder structure

    git-svn-id: http://<redacted>/trunk@7 4ed80924-4846-11e4-8279-c5809b3f22e4

commit 0c5873eab204942ffe56370cc6e1d31e5372da13
tree 4b825dc642cb6eb9a060e54bf8d69288fbee4904
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000

    new folder structure

    git-svn-id: http://<redacted>/trunk@6 4ed80924-4846-11e4-8279-c5809b3f22e4

(在完整的非标准布局存储库中):

commit ec52fff6ee1d65eadfa1d18aa4b74b553fc693e1
tree cfda32eb39248fa5969d15a21d2f8014189e88c2
parent 685fe9961abfee4d4913e83cf5a4a7e8d459a1a1
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411603 +0000

    change 4 after folder structure & branch

    git-svn-id: http://<redacted>@9 4ed80924-4846-11e4-8279-c5809b3f22e4

commit 685fe9961abfee4d4913e83cf5a4a7e8d459a1a1
tree 817306fad0ed5466d877437cdda12ff39a0df725
parent 02caf52174c588f1d394815201b764f9abdaa640
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411565 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411565 +0000

    created new branch

    git-svn-id: http://<redacted>@8 4ed80924-4846-11e4-8279-c5809b3f22e4

commit 02caf52174c588f1d394815201b764f9abdaa640
tree c041405a580beaef0a4e50923e9279e179c917a8
parent 37d77b8f1168d00b943e0bca3cab277cf89e7e84
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411513 +0000

    changed: moved to new folder structure

    git-svn-id: http://<redacted>@7 4ed80924-4846-11e4-8279-c5809b3f22e4

commit 37d77b8f1168d00b943e0bca3cab277cf89e7e84
tree d6c0d6cf271be5146b26781ab9bd78736d86ace3
parent 3a4784719bd95af5bf59de96310a1d6a38af562e
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411460 +0000

    new folder structure

    git-svn-id: http://<redacted>@6 4ed80924-4846-11e4-8279-c5809b3f22e4

commit 3a4784719bd95af5bf59de96310a1d6a38af562e
tree d6c0d6cf271be5146b26781ab9bd78736d86ace3
parent 2fb41dab5a7389ab32419b8b270d955631aaaefa
author (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411421 +0000
committer (no author) <(no author)@4ed80924-4846-11e4-8279-c5809b3f22e4> 1420411421 +0000

    update 4

... etc., continues.

请注意，在stdlayout存储库中，提交d403c6c是树d6c0d6c，在完整克隆中，提交37d77b8及其父提交3a47847也具有相同的树。一开始你可能会觉得这很奇怪，但当你意识到git-svn克隆中/trunk/branches/tags的创建实际上是一个无操作，因为Git不跟踪空目录时，就会明白了。
在stdlayout存储库中，您可以导入完整克隆非标准克隆：
# git remote add fullclone ../fullclone
# git fetch fullclone

从完整的代码库中“新文件夹结构”提交中检出一个新分支：
# git checkout -b fix-history 37d77b8

然后在标准布局的仓库中，从这一点开始重新播放所有的提交：

# git cherry-pick d403c6c..master

如果您有许多帖子重新组织的提交，这可能需要一些时间来运行，因为每个提交都会在新分支上重新提交。结果应该是一个将旧版和重新组织后的主干历史拼接在一起的结果。

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接