Migration from Subversion to Git in a company setting?

Question

Is there anyone out there whose company has migrated from a medium to large Subversion repository to Git? If so:

• What were the pitfalls you had to overcome?
• How easy was it for your developers to make the switch and learn Git?
• Is it a good idea for companies to migrate at this point or should they wait for Git to become more mature (e.g. at this point there doesn't seem to be a good Git Eclipse plugin, is that right)?

Answer 1

I have had great success using Git with Subversion. git-svn provides all the capability you need to access Subversion repositories using Git as a client.

One advantage of doing this is that people can choose when (and whether) to switch to using Git. If you've got Windows users, they might be more comfortable using TortoiseSVN (I know there's a TortoiseGit, but it's less mature).

Subversion integrates with more bug tracking software than Git does at the moment, too.

Answer 2

I'm actually in the middle of such a migration right now, migrating not one but six small-to-large svn repositories to git.

The biggest pitfalls have been:

• Inconsistent use of branches/tags/trunk "standard" svn structure, so I couldn't just write a simple script to do the conversions.
• Files checked in at the top-level alongside branches/tags/trunks -- where do I put those?
• Really twisted histories (e.g., a branch created and deleted multiple times) take git svn a long time to work out.
• svn repositories that are agglomerations of multiple projects get split up into many smaller git repos ==> repository number explosion, requiring management. (We're using gitosis + gitweb for that.)
• svn externals do not map smoothly onto any of git's solutions at the moment. We chose to use submodules but have had a lot of problems with them and will probably move to something else.
• Two of our teams make extensive use of keyword substitution in ways that map poorly to git, so we've had to write some scripts and hooks to work around that.

The switch has been somewhat mixed for the developers; some of them were using git-svn already while others don't use version control in very sophisticated ways (they don't branch, for example). I've been giving training periodically and people have adapted pretty well, with some quickly becoming power users that I occasionally have to restrain and others requiring hand-holding. I've done other migrations, for example from cvs to Perforce, and I'd say that this has actually been pretty comparable.

We're using git with all of our tools, including Eclipse, IDEA, Pulse (continuous integration server), FishEye+Crucible, ReviewBoard, etc., and while some of the integrations are still improving, all are usable. I don't personally use the Eclipse integration so I can't tell you whether or not it's really any good, but my Eclipse users are not complaining bitterly so I have to assume that it at least works. Obviously, we're using git in a central-server mode with the central repositories hosted on gitosis, but we also have people sharing code between themselves and we're planning to make use of more complex topologies as we move forward.

I should add that we switched because of three problems that we had with Subversion: Merging (the new merge-tracking solution doesn't work very well for repositories with lots of existing history); difficult to use offline (we have lots of remote developers); and data loss (we actually lost data due to a problem on the server side and could find no way to recover it). It's important to be clear about your reasons and goals for changing tools; it makes it easier to convince various stakeholders and it also helps you make decisions when you encounter problems in the migration.

Answer 3

I made the SVN to Git switch recently with a small team. Scott Chacon's new book, Pro Git, was a great help learning about all aspects of Git. The book is free and easy to use on the web site. The part about migrating to Git had some very nice tips to make your SVN-Git imports nicer.

Answer 4

I don't think it's necessary to migrate from Subversion to git at all. You can add git to what you're already doing pretty easily. Think of your git repositories as just really fancy Subversion clients, or think of your Subversion repository as a special source-of-truth git repository.

You may later find that the trouble of having a Subversion repository doesn't justify the effort to keep it current, and you can bid it a fond farewell. But while you're just migrating, I would keep the Subversion repository, letting those who prefer git to use git-svn and those who prefer svn.

ebneter's response is spot on on the nitty-gritty details - I'm just adding my opinion that Subversion/git aren't mutually exclusive.