1

I'm trying to migrate a very large svn repository and initially I just started a fetch from revision 13989.

This gave me the chance of having an uptodate git mirror which was awesome - but it took weeks to create.

Now I would like to get the full history in there (i.e. r1-13989) and tried doing:

svn git fetch -r 0:13989

(as described in Git svn clone: How to defer fetch of revision history)

This seemed to work (it was fetching for 3 days) but the files that before had their history abruptly end at 13989 before still has this abrupt end.

The new fetched revisions are not aligned into the history.

Any way to fix this other than having to start doing a full complete giv svn init/fetch again ?

Community
  • 1
  • 1
Max Rydahl Andersen
  • 3,630
  • 2
  • 23
  • 28

1 Answers1

0

Git commit ID is a hash of it's content. Including it's metadata including parent ID. Therefore specific commit can't have it's history modified, ever.

Git has a mechanism to fake parents to commits. It's called "grafts". (I don't remember exact details; look it up in documentation). It is local only as automatic sharing would be a security issue.

It also has a mechanism for rewriting whole history, the filter-branch command. That will create new history with new commit IDs that will have the parents you previously specified as grafts. If you are switching to git for good and will stop committing to subversion, you can just go ahead and filter-branch to apply the grafts. I am not sure whether git-svn will work after the operation though (or how to fix it up) as it has some additional metadata.

Jan Hudec
  • 73,652
  • 13
  • 125
  • 172
  • Thanks for the answer and yeah, hadn't though about the immutability of the history in the git repo that git svn needs to obey. unfortunately running git filter-branch on this repo is slower than actually redoing the full git-svn clone – Max Rydahl Andersen Sep 25 '12 at 08:55
  • @MaxRydahlAndersen: Which operating system? I wouldn't expect that on Linux where the network access in svn is going to be the main bottleneck, but can easily imagine it on Windows where the filesystem is a lot slower. Anyway, if that's the case, just redo the import and rebase any work not pushed to subversion. – Jan Hudec Sep 25 '12 at 08:59