In interest of a full comparison does anyone have a link to an article discussing the reverse topic of why subversion is better than git? Does such an article even exist or is git that much better than subversion?
I've never seen such an article and in my own personal opinion, I don't see how such an argument could be made. I'm not a fan of Git in particular, but I love the "distributed" in DVCS. I use BZR on a daily basis and have never once found anything I missed from the days all of our projects were in SVN. You can use most of the DVCS tools just like SVN if you want (checkout, update, checkin), or go all out distributed with branches, merges, pushes, pulls, etc.
I guess SVN gives you real Trac support. :-) There are Git, BZR, etc plugins for Trac, but they all feel very hacked in and incomplete to me. I love BZR because it gets you launchpad.net (and it's got some stellar Py-bindings). I know Git has github, but I don't care for it either as a real project management suite.
EDIT:
(Note: My opinions are from an open source developer perspective.)
My job in the past was to evaluate source control systems for different organizations and what made the most sense. While I think Git and Mercurial are great for open source pieces, I'd pretty much never recommend Git inside of a large organization just yet. Perhaps never given how much visibility and control most companies want on their internal development flow. Checking in code to local repositories on any large scale isn't something most companies are big fans of.
Overall, Perforce is probably my most recommended for companies, though it has its downsides. Subversion with their improvements to branching should be getting more props these days, though. ClearCase is preferred by a lot of process-focused software companies (government contractors, etc).
What I think traditional centralized systems need is a better story for local repos or at least private branches. It needs to feel natural and built-in so that smaller pieces of work can be handled quickly without necessarily shipping them to team branches (or main). It's all doable now but the emphasis and infrastructure should encourage incremental changes in isolation which Git and Mercurial do a great job of. This feature isn't one major organizations need as an essential, but developers sure know the importance of it.
The big failing of DVCSen is that you lose the ability to do fine-grained ACLs on code. For example, if a company wants to restrict access to certain parts of their codebase (eg, megacorp brings in contractors, they should see only the one tiny part of the code they work on), you can do that in svn, whereas with git you can't give them access to part of a repository. Heck, you can even integrate your ACLs with Active Directory if you have enough LDAP/Apache config fu.
Also, it makes pointy-hair types more comfortable to have a central server where everything is obviously canonical.
I don't think DVCS will ever fully supplant centralized systems (including Subversion, Perforce, and whatever else people use these days) in the corporate world.
Is it possible to pull out a portion of a project and then serve that as the canonical branch for the contractors? After the contractors git to their hearts content, could someone blessed to commit to a "master" then push only those changes or is that something that will not work?
I haven't used much git but they tout it as a very flexible system so I am wondering if it is flexible enough to accommodate this type of constrained work flow.
Mercurial and Git currently have no support for checking out part of the tree. It's been designed a couple of times for Mercurial, but never implemented.
(Git people: please correct me if that's changed since I looked last, a cursory Google search indicates this problem is unsolved as yet)
That's commit-time ACLs. I'm talking about read ACLs. Some companies aren't comfortable with giving people total access to code, even code that logically would sit in a single git repository.
