RhodeCode Enterprise 3 provides a central interface to Subversion, Mercurial and Git. Support for Subversion has been the biggest request from our customers. Almost all companies I’ve spoken to over the years want Subversion support to aid in migrating their developing environment to Git or Mercurial.
With RhodeCode Enterprise, developers can work with Git, Subversion or Mercurial in different teams at the same time. All the developers in a company can be managed from the same user base, have the same interface, but choose which repository type to use on a per-project basis. This provides legacy support for big Subversion repositories.
Developers using Subversion can now review comments and have read access permission. In the next few months, we’ll also add write support to enable developers to checkin and checkout through RhodeCode Enterprise to Subversion repositories.
RhodeCode Enterprise is not a tool to convert a Subversion repository to Git or Mercurial. There are already existing third-party tools to do this. RhodeCode enables the developer workflow to move from Subversion to Git or Mercurial.
I have experience with many companies that moved from Subversion to Git or Mercurial. These are the top three decisions that people face in a migration project.
1: Migrate or Keep
Should you move off Subversion OR keep Subversion while putting new projects on Git/Mercurial?
In actual practices, customers do both. Some will migrate their Subversion repositories to Git or Mercurial and other companies will run things in parallel.
Companies often keep their Subversion repositories because of the history or layout and then they’ll establish a policy where developers need to create new projects using Git or Mercurial, and prevent new projects from being created in Subversion. Often, it is hard for a company to port a huge project from Subversion to Git or Mercurial. In this situation, they’ll usually keep the existing projects on Subversion and start the new ones on the new technology. Or, they may just port a few of the main projects to Mercurial/Git, but keep the majority of their repositories on Subversion.
In both of these cases, the repository administrator is stuck having to manage different repository systems with different interfaces. It’s usually not realistic for the company to move all of their legacy repositories from Subversion to Git/Mercurial. With multiple repositories, the enterprise developer also has a different way to interact with each type of repository technology.
Of course, with RhodeCode Enterprise, everyone has an unified interface regardless of what repository they use.
2: What to keep in Subversion - When does Git fail and when is Subversion
better?
For storing large files, Subversion is still better than Git. For example, I worked with a company that had a very large repository that they migrated to Git. Unfortunately, due to the large size of files, Git gave them so much trouble that they moved back to Subversion. This is not a typical case and for most cases, Git would work better. It’s important to be aware of the strengths and weaknesses of Subversion, Git and Mercurial. In most cases, Git and Mercurial will be the better choice, but not in all cases.
3: Git or Mercurial - Should I move to Git because everyone else seems to
be?
Both Git and Mercurial provide the same functionality. In my opinion, Mercurial is simpler. The migration from Subversion to Mercurial is also easier because many of the commands are the same. Everyone automatically thinks of Git, but in the case of moving from Subversion, you need to take a deeper look at the technology and see which is the best technology for your migration. In many cases, you’ll save time and money by moving from Subversion to Mercurial instead of from Subversion to Git.
For example, Facebook invested a huge amount of money migrating from Git to Mercurial because Mercurial gave them an easier way to extend the repository functionality. There is a huge plug-in community for Mercurial and that could be a consideration. There’s also a rumor that at the scale of Facebook, the Git repository ran into performance problems.
Summary
You need to answer these questions prior to migrating your development team from Subversion. Making a wrong decision will waste your own time and possibly the time of an entire development team if you move the workflow to a new repository and then run into unexpected problems with scale, performance, or extensibility.
We see a definite trend that companies are migrating from Subversion. Often, they’ll migrate to Git because it is more popular. We also see a number of companies migrating to Mercurial. Spend some time to research the best decision for yourself.
RhodeCode can help. Download the free trial and try it out for yourself. Alternately, check out the instant demo container for immediate access in seconds. If you have questions about migration from Subversion, please write them in the comments below and I’ll try and answer them based on my experiences.