Svn to git migration: an incomplete history

Question

I am migrating my SVN repository according to this answer. Everything goes smoothly, except that in the end I do not have a complete story. I could trace the source of the problem to the "SVN move" that I did.

Here's what I did: At the beginning, my SVN repo did not have trunk branches tags dirs. Once I introduced them and moved everything to the trunk (and then I created a branch, so I decided to introduce a new folder structure).

So, after transferring the SVN repo to git, only the history is available after the introduction of the new folder structure.

I reproduced this problem in a very simple scenario.

History at SVN:

History in git:

ZIP code containing SVN repo / git repo:

https://www.dropbox.com/s/ecy54st05qah4up/svn_git_problem.zip?dl=0

Is there any way to fix this?

Answer 1

When you specify --stdlayout , git svn clone will only pay attention to svn commits that modify files along the path / trunk, / branch or / tags - other commits will be ignored. You still get a valid clone of your repository, but the story from r1 to creating your standard layout will be lost, as you noticed. Since you want your Git repository to understand the connecting lines, branches and tags after changing the layout, you still want --stdlayout , otherwise Git clone will merge all the branches into one tree with / trunk / branch / tags, which is not what you want to.

What can you do if you seriously care about the history of changes in history (and if it is strictly one-way migration, SVN is not fixed after switching to Git), then you need to run git svn clone twice - once with --stdlayout and once. The stdlayout version will become your potential repository, and the non-stdlayout version can only be used during the migration to sew the change history before the layout under the new layout at the time of the reorganization. This can be done using cherry capture, all of your post-reorganizations are captured on the repository image during the reorganization.

As soon as you clone both repositories, you will notice that at the copy point of the new layout there is a common tree hash for the chest. Here is an example (without using your repo, sorry, so the hashes are different):

(in stdlayout repo) :

 # 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 

(in full, non-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. 

Note that in the stdlayout commit repository d403c6c is a d6c0d6c tree, and in the full clone, both commits 37d77b8 and its parent 3a47847 also have the same tree. At first, you might think that this is odd until you realize that creating / trunk / branches / tags in the git-svn cache does not actually work, since Git does not track empty directories.

In the stdlayout repository, you can import the full clone of a non-standard clone:

 # git remote add fullclone ../fullclone # git fetch fullclone 

Then write a new branch from the “new folder structure” from the full repo:

 # git checkout -b fix-history 37d77b8 

Then repeat all the commits from this point forward in the standard repo layout:

 # git cherry-pick d403c6c..master 

This may take some time if you have a lot of messages about re-organization, as each commit is intercepted in a new branch. The result should be a stitched history of the trunk pre and after the reorganization.