@rpr: Ich arbeite mit Subversion und Git (wobei ich inzwischen fast alle Projekte auf der Arbeit auf Git an SVN-Server umgestellt habe). Beide sind nicht schlecht, aber insgesamt hat Git (für mich) sehr viele Vorteile. Insbesondere Branchen und Mergen funktioniert einfach so gut, dass man es immer macht - Ich mache es teils sogar für 1-Tages-Features. Bei SVN funktioniert insbesondere das Mergen von Branches nicht so gut, daher vermeidet man Branchen oft ganz (ich musste mehrfach alles per Hand kontrollieren, weil SVN versagt hatte). Uns ist deswegen gerade wieder eine Änderung online gegangen, die noch nicht sollte, weil derjenige aufs Branchen für eine 14-Tage-Änderung verzichtet hat.

SVN ist oft natürlich noch besser eingebunden in die IDEs. Aber TortoiseGit steht TortoiseSVN nicht mehr nach und zusehends mehr IDEs können Git vernünftig ansteuern (Wobei ich sowohl bei SVN als auch Git alles über die Konsole committe). Und gitk (bzw. gitx auf dem Mac oder gitg auf Linux) vermisse ich jedes Mal schmerzlich, wenn ich wieder mit SVN arbeiten muss.

Man sollte Git (oder Mecurial/Bazaar) mal bei einem Projekt ausprobieren. Wem es nicht gefällt, kann ja immer noch zurück.

Unit-Test: Die müssen natürlich gewartet werden. Bei Rails bin ich inzwischen auf Test-Driven-Development umgestiegen. Das ersetzt natürlich keine manuellen Tests, verhindert aber, dass einmal gemachte Fehler (für die man Tests geschrieben hat) nochmal macht.

Tests schreiben braucht Erfahrung, aber dann geht es recht schnell. Und der Entwickler muss da auch hinterstehen, sonst testet mal halt irgendwas, aber nichts sinnvolles. Wenn man einmal ein ordentliches Testframework hat, kann man auch bei Code, den man selbst länger nicht angefasst hat oder den jemand anderes programmiert hat, sehr viel sicher sein, dass man mit den neuen Änderungen nichts kaputt macht. Von meinen Kollegen höre ich hingegen öfters: Nee, dass fass' ich nicht mehr an, das fällt alles auseinander.