Git Adoption Soaring; Are There Good Migration Strategies?

Got To Get Me A Git writes "Distributed version control systems (DVCS) seem to be the next big thing for open source software development. Many projects have already adopted a DVCS and many others are in the process of migrating. There are a lot of major advantages to using a DVCS, but the task of migrating from one system to another appears to be a formidable challenge. The Perl Foundation's recent switch to Git took over a year to execute. The GNOME project is planning its own migration strategy right now after discovering that a significant majority of the project's developers favor Git. Perhaps some of the projects that are working on transitions from other mainstream version control systems can pool their resources and collaborate to make some standardized tools and migration best practices documentation. Does such a thing already exist? Are any folks out there in the Slashsphere working on migrating their own project or company to a DVCS? I'd appreciate some feedback from other readers about what works and what doesn't."

Comments

Re:strategy

[drinkypoo]

As just some schmuck who downloads sources over the internets for compilation, I will give my POV: git is shit! So far I have done pulls from cvs, cvsnt, svn, git, and mtn that I know of. Of these, the only one worth one tenth of one shit from the user's perspective is svn. Why is that? Because every other remote source code control system will happily corrupt your copy of the repository the majority of the time that there is some communications problem. In the case of svn, you can at least almost always resume a get. svn was invented specifically because cvs couldn't do this properly; with cvsnt it is possible to complete the get with a bunch of sub-gets. Monotone and git both do a WHOLE BUNCH of transfer before actually even sending any files, so if you have users on slow links, they are NOT repeat NOT a fit for you.

If you will never open up remote access to your source, then perhaps any repo will do for you. But if you plan to open up remote access, PLEASE do not use anything other than svn. Subversion can be painful too (why they couldn't create .svn/tmp directories in the new version instead of just failing because they weren't there, I don't know, but I suspect it can be traced back to developer laziness.)