SVN vs. GIT: Why not jump into the battle?

So much has been said of this little battle that I can't help but put my oar in as well.
For those of you who don't worry about these things, SVN (subversion) and GIT are Source Code Management programs/systems/whatever. In a nutshell, they allow programmers to make sure they 1.) always have the latest version of a project their team is working on and 2.) are able to roll back to an older version if the new version turns out to be fatally flawed.

The major difference between SVN and GIT is the nature of the "repository" or common storage that each uses.  SVN resides on a server that all team mates can get to, and they each check out a copy of the code, make their changes, and then commit their changes back to the repository when they're done.  GIT is the same, except each programmer checks out the entire repository and makes changes first to their local "clone" and then eventually merge those changes back to the central repository, where they are propagated to all the other team members.

All this is good and fine, but from a user's perspective the differences are minimal.  What really matters is how easy it is to commit your changes.

For some perspective we go to the best thing to come out of Microsoft: Code Complete 2nd Edition by Steve McConnell:

In mature technology environments—[SVN, for our purposes]—we benefit from a rich software development infrastructure. ...The tools are well documented in vendor literature, in third-party books and articles, and in extensive Web resources. Tools are integrated, so you can do [everything] from within a single environment. If you do run into problems, you can readily find quirks of the tools described in FAQs. Many consultants and training classes are also available.

And this holds true.  SVN is integrated into Eclipse (two or three different ways, Eclipse being what it is), Komodo, TextMate, and all the other big names in software development.  Ruby on Rails developers can use Capistrano to automatically upgrade their apps using SVN.  This means that I can be working in Komodo and when I'm happy with my code I press a button and Komodo handles the process of committing my changes; no command line, no mess.  If I'm using an IDE that doesn't support SVN Visual Studio then you can use TortiseSVN on Windows to handle all your checkout/commit/change/switch/branch/tag etc. needs from the Explorer, with pretty icons to let you know the status of all your files from Windows itself.  Mac users can use Versions (in beta but pretty good) to get some of the same functionality.

Returning to Mr. McConnell for the other side of the coin:

In early-wave environments—[GIT, for our purposes]—the situation is the opposite. Few ...choices are available, and those...tend to be buggy and poorly documented. Programmers spend significant amounts of time simply trying to figure out how the language works instead of writing new code. Programmers also spend countless hours working around bugs in the language products, underlying operating system, and other tools. Programming tools in early-wave environments tend to be primitive. ...Vendors revise their compiler version often, and it seems that each new version breaks significant parts of your code. Tools aren't integrated, and so you tend to work with different tools for UI, database, reports, and business logic. The tools tend not to be very compatible, and you can expend a significant amount of effort just to keep existing functionality working against the onslaught of compiler and library releases. If you run into trouble, reference literature exists on the Web in some form, but it isn't always reliable and, if the available literature is any guide, every time you encounter a problem it seems as though you're the first one to do so.

Grim, no?  Actually not really. Living on the edge can be fun, and there is often a very good reason that the current up-and-comer is an up-and-comer.  GIT's distributed methodolgy removes the single point of vulerablility that has plagued SVN, and may well repace SVN as the de-facto standard, just as SVN replaced CVS. (This article could just as well have been about Ruby being the new PHP, just as PHP is the new Perl, just as Perl is the new Awk...and so on. But I'm not nearly crazy enough to jump into the Rails/PHP/NetBeans/Coldfusion battle.) But for now switching to GIT means that there is no Komodo integration, primative Eclipse integration, (TextMate, of course, already has an excellent GIT bundle) and users of Visual Studio and other non-integrating platforms are forced back to the command line for all their actions.   More steps means more people forget to take those steps, which means that more people lose their work to midnight "it seemed like a good idea at the time" edits and hard disk failure. 

So what do you do?  Should we always wait until something is mature to use it?  No.  New things often have very good reasons to exist, and we should learn them, even if only to keep ourselves from getting stagnant and sounding like Richard Stallman.  But if you are coming up on a deadline (like I am now) then this might not be the exact right time to try to piece together a new CMS/IDE/OS combo.

I mention this because my workplace just moved me, at long last, from a Windows XP system to an iMac, and I am doing a lot of system setup in the face of deadlines, and the wisdom of not doing exactly this is staring me in the face.

Anyway, feel free to let me know what your favorite CMS is, and thanks! (Perforce users need not apply.)