我正在根据this回答迁移我的SVN存储库。 一切顺利,但最后我没有完整的历史。我可以跟踪问题的根源到我做的“SVN移动”。
这就是我所做的:
起初我的SVN回购没有trunk
branches
tags
dirs。当我介绍它们并将所有内容移动到主干中时(然后我创建了一个分支,这就是我决定引入新文件夹结构的原因)。
因此,在将SVN repo迁移到git后,只有引入新文件夹结构后的历史记录才可用。
我在一个非常简单的场景中重现了这个问题。
SVN的历史:
git中的历史:
包含SVN repo / git repo:
的ziphttps://www.dropbox.com/s/ecy54st05qah4up/svn_git_problem.zip?dl=0
有什么方法可以解决这个问题吗?
答案 0 :(得分:2)
当您指定--stdlayout
时,git svn clone
将仅关注修改path / trunk,/ branches或/ tags下的文件的svn提交 - 其他提交将被忽略。你仍然最终得到了你的存储库的有效克隆,但是正如你所观察到的那样,从r1到创建标准布局的历史将会丢失。由于您希望Git存储库在布局更改后了解主干,分支和标记,您仍然需要--stdlayout
,否则git clone会将所有分支组合成一个带有/ trunk / branches / tags的树,这不是什么你想要的。
如果您真的非常关心布局前更改历史记录(如果这是严格的一次性迁移,移动到Git后没有SVN提交),您可以做什么,是运行git svn clone
两次 - 一次使用--stdlayout
,一次不使用# 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
。 stdlayout版本将成为您的最终存储库,并且只能在迁移期间使用非stdlayout版本,以便在重组时缝合新布局下的预布局更改历史记录。这可以通过在重新组织时挑选所有重组后提交到存储库的快照来完成。
一旦你克隆了两个repos,你就会注意到在复制到新布局时,有一个常见的树干哈希。这是一个例子(不使用你的repo抱歉,所以哈希不同):
(在stdlayout repo中):
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
请注意,在stdlayout repo中,提交d6c0d6c
是树37d77b8
,在完整克隆中,提交3a47847
及其父# git remote add fullclone ../fullclone
# git fetch fullclone
也具有相同的树。一开始你可能会认为这很奇怪,直到你意识到git-svn克隆中的/ trunk / branches / tags的创建实际上是无操作,因为Git不跟踪空目录。
在stdlayout仓库中,您可以导入完整克隆的非标准克隆:
# git checkout -b fix-history 37d77b8
然后从&#34;新文件夹结构中检出新分支&#34;从完整的回购承诺:
# git cherry-pick d403c6c..master
然后在标准布局回购中重播所有提交:
{{1}}
如果您有许多post-org提交,这可能需要一段时间才能运行,因为每个提交都会在新分支上重新提交。结果应该是重组前后的树干拼接历史。