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.
It's because svn lacked the proper data structures to accurately determine the latest common ancestor of the two branches. That's not a big deal for a branch that is only merged once, but can cause a lot of erroneous merge conflicts in situations where several branches are merged multiple times.
I don't follow svn very closely, but my understanding is those particular technical issues have been fixed in recent versions. However, it wasn't fixed early enough to dispel the myth, and people who tried DVCS for the merges have stuck with it for other reasons.
Best Answer
Very good, especially given perforce's competition (cvs, svn, etc) over most of its life, but no, not as good as Git. I can't speak to hg.
While some of this is off-base (the p4 shelf is now an old feature, no, you can't make a dvcs behave just like a vcs, and it seems silly to knock p4 for xcode dropping support) the choice bits about p4 merging headaches are accurate.
I don't think there's anything inherent to a distributed version control system that makes its merging naturally superior to a centralized system like perforce. Rather, the data models adopted by many dvcs's lend themselves to superior branch and merge tracking.
Perforce branch mappings? A cumbersome alternative to git's pointers and directed graph approach.
One key advantage of git over perforce -- tracking code through refactoring -- has nothing to do with git's status as a distributed version control, but rather the fact that it looks at both files and blobs of content as first class citizens in its data model. This is completely different from perforce, which keeps extensive metadata in its database on a file-by-file level: file state, history, attributes, changelists, while versioned file content is stored separately in a filesystem hierarchy.
Lastly, and this may be a bit unfair but I feel that if a version control system needs to have a file locking feature, it probably doesn't bode well for its branching and merging sophistication.
For a biased comparison of git vs. perforce (archived link). I also find it telling that perforce has itself jumped on the gitwagon.