Der Punkt der mir da (Systembedingt) absolut fehlt, ist der zentrale Server an dem zwangsläufig alle Sourcen jederzeit zur Verfügung stehen und gesichert werden können. Lokale Stände sind für mich nicht gesichert und damit nicht tolerabel. Gibt es da evtl. inzwischen abhilfe?
Wenn man nur einen
SVN-Server hat, würde ich von
gesichert auch nicht gerade reden. Da hast du einen "single point of failure". Bei DVCS hat hingegen jeder Klon die
komplette Versionshistorie und es kann deshalb von jedem Klon die Entwicklung wieder aufgenommen werden, sollten alle anderen in Rauch aufgehen. Versuch das mal mit
SVN-Arbeitskopien
... seine Entwickler muß man allerdings soweit im Griff haben, daß sie regelmäßig einchecken/pushen. Wobei ich da verschiedene Typen kennengelernt habe und eben leider auch den der nur alle paar Tage oder Wochen Sachen ins
CVS/
SVN eincheckt. Die Arbeit wäre auch verloren und dank
CVS/
SVN ist das Mergen auch nicht gerade einfach wenn die Entwicklung auf dem Zweig inzwischen weiterging. In Mercurial bekomme ich Merge-Konflikte als Benutzer höchst selten zu sehen, da alle Metadaten über die Abstammung der aktuellen und zusammenzuführenden Dateien mit in den Vorgang einfließen und deshalb eine insgesamt weit bessere Zusammenführung als bei den traditionellen VCS ermöglichen. Und von "hunk selection" und "shelving" haben wir da noch nichtmal gesprochen.
Die andere Sache ist das Tooling. Für welche Systeme gibt es denn inzwischen gescheite
Gui's (=mindestens so gut wie TortoiseSVN und Ankh)? Bei Git braucht man dazu dann ja noch Cygwin etc. - und das ist mir alles zu aufwändig dafür, dass ich auf den grössten Vorteil von
SVN, nämlich die zentrale kontrollierte Datenhaltung, verzichten müsste.
TortoiseHg finde ich sehr gut und die Entwicklung geht flott voran. Allerdings habe ich noch nie einen Vorteil in der
IDE-Integration gesehen und daher noch nichtmal geguckt ob es eine solche für Hg gibt. Für Bazaar gab es damals schon TortoiseBzr, in welches ich seit Monaten aber nicht mehr reingeguckt habe.
Der größte Vorteil von
SVN, "die zentrale kontrollierte Datenhaltung", wird auch nur dann erreicht wenn deine Entwickler mitspielen. Automatisches einchecken ist nämlich auch bei den klassischen VCS problematisch, wenn der Code auf dem aktuellen Zeig stabil sein soll etc. Und da eine willentliche Intervention - nämlich das Einchecken - ohnehin notwendig ist, kann man a.) per Konvention einen zentralen Server festlegen auf den manuell alles geschoben wird und/oder b.) eine Erweiterung (bei Hg in Python) schreiben welche das Hochschieben evtl. direkt nach dem Commit automatisiert. Sehe ich also nicht als Problem. Ich will dir nicht zu nahe treten, aber das große "Gegenargument" klingt wie jene die ich mir bisher anhören mußte wenn es um die Einführung von (nahezu beliebigen)
Änderungen ging. Die meisten Leute hassen Veränderungen - einige wenige vielleicht aus Prinzip, aber meiner Erfahrung nach ein großer Teil auch weil sie mit Lernen verbunden sind und damit die "Spurrinnen" in den Hirnen der Verweigerer allzu deutlich sichtbar machen würden.
Die Vorteile von DVCS sind sicher bei FOSS-Programmierung noch deutlicher ausgeprägt als bei proprietären Projekten, aber sie sind dennoch auch für den kommerziellen Einsatz vorhanden und (für mich und diverse Kollegen) überzeugend.