SVN to GIT

SubGit
#1

Hello Team,

I want to migrate source code from SVN to GitHub Enterprise Server. Does this tool support?
I don’t need any sync between both SVN and GitHub, Once the code is migrated I’ll use GitHub as an SCM. This will be supported?

Thanks,
Guru

#2

Hello Guru,

thank you for your interest in our product!

Basically, SubGit works with Git repositories directly and thus requires direct filesystem access for full-blown mirror or import – but this functionality has never been tested with GitHub Enterprise Server.

However, it is also possible to run SubGit on an interim server which would push changes from SVN to a remote Git repository and such a setup is possible with vurtually any Git server or service, including GitHub or GitHub Enterprise Server. Here is our documentation article that describes such a setup:

TMate SubGit: SubGit for GitHub

For the one-time import you mentioned this would be the best approach, you’ll only need and interim server for the first import.

#3

Hello Ildar,

Thanks for your email. SubGit will work if SVN doesn’t have a branching strategy as well correct?

#4

Hello Guru,

I’m afraid I don’t completely understand what branching strategy is in this context, do you mean SVN branches import from SVN to Git? If yes, then it’s perfectly possible, SubGit does support importing all the branches, the crucial condition is to add the branches into SubGit’s branches mapping configuration so that SubGit is aware which SVN directories should be considered as branches and which Git branches should be created. Here is another documentation article that describes the branches mapping concepts:

TMate SubGit: Branches and tags mapping

If, on the other hand, the branching strategy means something different, could you please elaborate this a little?

#5

Hi Ildar,

Thanks for the quick response. You’re truly amazing. Yes, the above-provided info is sufficient I guess. I have tried migrating source code using a couple of other tools like svn2git and git-svn. Those have some limitations, Started looking for alternate tools and came across SubGit. Still reiterating the problem statement, I’ve code in SVN where it doesn’t maintain correct standards like trunk, branches, tags and etc.

How long does it take the code to import? Consider it has 60k 70k commits and size is around 10GB. With the earlier tried tools used to get stuck at 50k commit and doesn’t move forward.

Assume I started using SubGit and started importing code and it imported 50k commits out of 60k commits, The remaining 10k commits which left are the latest or older ones?

#6

Hi Guru,

Basically, it does not matter much for SubGit is those standard layout is strictly followed, virtually any layout can be imported to Git yet it would, of course, require an appropriate mapping configuration that would reflect actual SVN repository layout.

It’s very hard to predict precisely how long a particular repository import would take as the import process time depends on many things like the SVN and Git server performance, network speed, the import settings (like, do or do not perform EOL translation), actual repository layout, size, and history, and actual import configuration. At a rough average estimation, one single “code-changing” revision translation takes about 1 - 1.5 seconds, but I wouldn’t expect that the import time would be equal to number of revisions multiplied by 1.5, it may differ due to the reasons above.
Here is our another article that describes the initial import performance:

TMate SubGit: Frequently asked questions

It describes some of the factors that may affect the initial import speed, hope it will be helpful.

And for the repository size and history – we had cases importing repositories up to hundreds of thousands revisions and hundreds of gigabytes in size, so 70K/10GB is definitely something SubGit is able to deal with. I’m not sure why the other tools stuck at 50K, but we also saw many times SubGit was able to handle repositories other tools were unable to import, so this issue may not even be present with SubGit. But even if it happens, SubGit usually clearly shows what the issue is, so it is possible to solve it or at least work it around.

SubGit always starts the import from the very least revision – a revision set by svn.minimalRevision which is r1 by default – and translates revisions one by one moving along the history towards the very last one. Some of the revisions may be omitted according to the configuration, but still, if SubGit stops somewhere in the middle of import process, the remaining revisions are always the latest, not older ones.

#7

Hi Ildar,

Thanks for the explanation. I will check the same with the team and try SubGit and let you know the updates.