Subversion and GIT centralization

Question

I have been using subversion for a while now and I am considering learning and switching to GIT, since it seems to be the majority's preference nowadays.

Nevertheless, one of the biggest advantages of GIT (and source of its complexity) is the capability of being decentralized, each person having its own repository and merging repositories whenever needed. I am not interested in this feature, and actually I want to keep everything centralized on a single server, both for projects on which I work alone, as well as projects where multiple people are expected to have the latest sources at all times stored on the same server, with none or a minimal amount of branches/forks.

Considering this, and that currently most of the development is done on Windows with Visual Studio and also some access is needed from Linux using some simple svn commands, is GIT still a good option? would it be worth switching? what other features does GIT offer that would benefit us?

Answer 1

Let me get this straight.

• You are using Subversion quite successfully.
• You don't want to use the distributed features in Git.
• You are using VisualStudio development.

So, why switch to Git?

I know there's a lot of chatter on Git "being better" than Subversion, but most of that are people who really don't know version control. They see many open source projects use Git and assume that if Linux is using Git, it must be better.

I use both Git and Subversion, and find each one has their strengths and weaknesses.

• Git is great when there is no central repository. Actually, that's your only option.
• Git is great if you don't want to get into the details of user access. You give key gatekeepers access, and let them figure out who is allowed to submit code changes.
• Git is good with a pure Agile shop. That is, a shop that has no fixed release schedule or customer commitments. In fact, the true Agile processes were designed with Git in mind.
• Git is also great when all of your developers are top rated stars. These guys know Git. They share repository access with each other. They test, they integrate, they scheme, they work with each other. They don't need a project manager or a configuration manager which is why I don't get to work with such star teams too often. Thankfully for me, most development teams aren't top tier teams. Otherwise, as a CM, I'd be out of a job.

Git's problems start to show up when you have customer imposed deliverables and release deadlines. Git just doesn't work well with a Continuous Integration environment unless you're on your developers like a mother hen. What happens is that no changes are delivered to the central repository until the end of a release cycle. Then, you're stuck trying to handle incompatibilities, conflicts, and other issues the last few days of a release.

With a centralized repository like Subversion, developers are forced to work together. They make smaller, more incremental changes in their code. With a good Continuous Integration environment, your QA team can pull out intermediate releases and do testing without waiting for a final release.

As a bonus, Subversion has an excellent integration to VisualStudio via AnkhSVN. There's finally a Git Source Code Provider for VisualStudio, but it's dependent upon TortioseGit and to the BASH shell. Meanwhile, AnkhSVN is a completely encapsulated source code provider whose interface is similar as if you were using VisualStudio or TeamFoundation, so VisualStudio developers are quite familiar with it.

So, unless all of your developers want Git, or you plan to use the distributed features of Git, there's really no reason to switch just for the sake of switching.