Disclaimer: as said below, I never used GIT for development, so the characteristics that I attribute to it are based on what I have heard about it from other developers…
I personally have been and still am a supporter of SVN, and of the fact that (as some friends noticed) it’s not so cool having to download, with GIT, the whole project history just for trying some new features in trunk/ (but maybe there is an option to avoid it, I don’t remember exactly…); as of today, I have only used SVN for my projects (GIT and CVS only for downloading some bleeding edge software), and I also have a local repository with that VCS.
But, in the last weekend I started to rethink this fact: developing my GSoC project, I often had the necessity to create a local branch on the fly, sometimes because, in the middle of the development of a new feature, I or someone else found some serious bug, which should be solved asap and its new code uploaded in the remote repository, sometimes because there were more than one way for solving some problems, and it would be nice to try them in parallel, sometimes because you just want to revert only a part of the last modifications, but the revert option erases everything…
I admit that having a good IDE, with a good history of last modifications, may help in this way (and Eclipse, my usual IDE, does help), but it looks like that, in the end, a distributed VCS does make the difference, so I may start to try GIT for real, and then I’ll tell you if it is worth develop with it…
Syvo3 
Hi, there.
I used to be a *huge* SVN fan, and now I converted to an even *bigger* fan of distributed VCSs. Mercurial looks simple, elegant and nice, and the learning curve from Subversion seems excellent. Then Git is slightly harder to use, but it’s incredibly fast and its ability to operate with SVN repositories almost transparently made it my choice. If you don’t want to download the full project history from a Subversion repository, just do the following:
git svn clone -r :HEAD
It will save you a lot of space.
Cheers.
DAMMNIT!, it messed up my git command! I meant:
git svn clone -r INTERESTING_POINT_IN_HISTORY:HEAD SVN_URL
Or, just fetch the HEAD:
git svn clone -r HEAD SVN_URL
SVN2GIT migration can be hard.
I like this:
http://tom.preston-werner.com/2009/05/19/the-git-parable.html
Just forget about SVN before reading it. (Getting totally wasted helps 🙂
git help clone reveals:
–depth
Create a shallow clone with a history truncated to the specified number of revisions. A shallow repository has a number of limitations (you cannot clone or fetch from it, nor push from nor into
it), but is adequate if you are only interested in the recent history of a large project with a long history, and would want to send in fixes as patches.
Maybe my perception is just faulty, but cloning from a git repository always seems faster to me than checking out from svn – even though you’re getting the entire history. I imagine that might not scale to something like KDE though. Does svn use compression? That might be the difference.
With git, the _entire_ project history still takes up a lot less disk space than a single svn checkout. (This is true for Qt with 15 years of history. It’s probably also true for KDE)
Btw I’m also a huge git fan.
The only people who are unsure about the value of distributed VCS systems are people who have never used one 🙂