Well I am not going to start debating over this question, as most people on the web are doing so. I am not going to list pros and cons of both svn and git and make a vague conclusion in the end. I being a user of both svn and git, found git better for the kind of work I do and the way I do it. I was mainly a svn user before I heard people talking about git being easier etc. than svn; after I started using git I agree with these people. With git, it is much easier, simpler, faster and natural(in the realm of development) to manage your code, to create and clone repos; branch, tag and merge code. Apart from being simple and powerful, git is also decentralized and distributed in nature, which undoubtedly is git’s main advantage over svn.
Now I found git better because I no-longer have to think about problems and limitations associated with svnsync; with git I can clone my repositories, pull and push my changes from anywhere in the world. In fact git allows ubiquitous transactions, so one doesn’t have to be connected to the main repo (as in svn) to check in changes. One also doesn’t have to remember branch or tag locations like with svn. I sometimes work while I am traveling, when I am in a different city or country; so now, with git, I don’t have to care from where in the world I am pushing files to which mirror of which repository; in other words I won’t indulge myself in the master-slave repo setups like in svn, in git every clone of a repo is truly “equal”, master and slave at the same time. Security is one area where git needs to focus on more, because it is decentralized; but the current asymmetric encryption for all transactions seem to suffice.
There are many other things one can talk about, there are pros and cons of both SCMs. But in the end I would say that gradually people should try and move away from a centralized repo to a more distributed SCM because of many advantages, some of which are described above.
I have been using googlecode for some of my recent open source development work, and I was surprised how googlecode speeds up development. The SCM is very fast and gave me no troubles, it is easy to create wiki pages and documentation for projects etc. etc. Although it offers limited features, compared to sourceforge for example, but the real power is in its simplicity. Sourceforge offers more features like, hosting web pages and shell services and if you are smart you can also create your own little maven repository for your artifacts; one might argue that all these features make sourceforge very complex. But recently sourceforge has become slow as hell, and it is bit of a pain to manage your work, SCM is slow, web pages are not served with a desired speed, shell services (although more secure) but slower and the whole shell-creation process takes too long. So to cut the story short, I finally decided to migrate some of my work from sourceforge to googlecode, simply because googlecode is faster and simple.
In the beginning I had no clue how to achieve this task. But it was much simpler than I anticipated. My only concern was to get the code migrated fully, safely and with all the version history. This is done by synch’ing the project’s SVN repository on googlecode with the repository on sourceforge. First I reset the googlecode repository to enable svn synch’ing. This is done under Administrator->Source tab on your project’s homepage on googlecode. Then I began the synch’ing process.
The first step is to initialize the googlecode’s subversion repository
svnsync init --username [user] --password [pass]https://[project].googlecode.com/svn/trunk/ https://[project].svn.sourceforge.net/svnroot/[project]
After this we just start synch’ing the repositories.
svnsync sync --username [user] --password [pass]https://[project].googlecode.com/svn/trunk/
The above command will fetch all the code, with the version history and including tags and branches.
And this is all to it. For more information on the svnsync refer to the subversion redbook.