Hmm, having been a manager I have two immediate "knee-jerk" reactions to this:
- If you don't already have good reasons why are you pitching git other than to be trendy?
- Similarly, how is Subversion failing such that you need a replacement?
I'm not, actually, being negative - I think there probably is a case to be made (dependent on circumstance) but if the case is simply that git is "better" than subversion then you don't really have one.
You also need to be able to enumerate the disadvantages - you've already identified the overhead of migration and re-tooling - what else is a problem? e.g. What happens to your nice, central, backed up repository? How do you integrate with your continuous integration build server (if you don't have one, forget git and go sort that first). Oh security and tracking - SVN runs with proper logins and permissions.
To my mind, the benefits are in flexibility, better merging, the ability to do local commits without breaking the build and so on. The disadvantages are in lack of control and that same flexibility.
It may be that all you want to do is run git locally to your machine as a "better" subversion client (I'm looking at doing this using mercurial).
Hmm, perhaps this whole answer is a comment really? You need to make your case here (in the question) for git over subversion (in your environment) in order to see if we can help you identify the business case.
FWIW, I'm know that one can easily designate a specific instance of the repository to be the trunk/reference source and further that that is how one wires into one's build server - the difference being that with DVCS that's more of an administrative decision than something inherent in the architecture.
Main internal structural differences I can think of:
- On distributed you get all the previous versions with each pull/get
- On distributed you don't have to phone home when you are about to start editing a file.
- On distributed you will have to have all the functionalities of merging, checking in, etc, because each instance is a full-featured repository
As far as a client goes, a non distributed source control client would be ok if it could do the basic tasks of: getting a specific version, phoning in to tell that you are working on a file, and sending back the changes after looking/resolving any conflicts
Best Answer
"Local", "centralized" and "distributed" are synonymous with "here", "there" and "both", respectively.
The only thing that is neither here nor there, is nowhere. So I guess the only other type of version control is "Non-Existent VCS" which, unfortunately, is still quite prevalent in the industry.