Well, here's why distributed is better than centralized:
You're working on something in SVN. You've made progress that you'd hate to lose, but it's not great yet. Which do you do?
1) Don't commit until it's great. This prevents bugs from hurting your colleagues, but puts you at risk of losing work or being unable to undo mistakes - in other words, it's just like not having version control.
2) Commit a lot. Opposite problem - your teammates get your bugs.
Distributed version control lets you have both benefits: commit locally as often as you want, and push it up when it's good.
(I think I stole this explanation from Joel Spolsky. Whoever said it, it was what made me realize I should learn a distributed VCS.)
P.S. If your answer to the dilemma above was "use a branch until you're ready," well, OK, but branching in SVN is painful and slow, requiring making a copy of every file in the repo.
You're working on something in SVN. You've made progress that you'd hate to lose, but it's not great yet. Which do you do?
1) Don't commit until it's great. This prevents bugs from hurting your colleagues, but puts you at risk of losing work or being unable to undo mistakes - in other words, it's just like not having version control.
2) Commit a lot. Opposite problem - your teammates get your bugs.
Distributed version control lets you have both benefits: commit locally as often as you want, and push it up when it's good.
(I think I stole this explanation from Joel Spolsky. Whoever said it, it was what made me realize I should learn a distributed VCS.)
P.S. If your answer to the dilemma above was "use a branch until you're ready," well, OK, but branching in SVN is painful and slow, requiring making a copy of every file in the repo.