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
Dafür gibt's ja die nächtliche Filesystem-Sicherung des Servers off-location. Ist ja nicht so, dass der Server ungesichert wäre. Und ja: das Rückspielen des Backups wird regelmässig geprobt. Ist ja nicht so dass man nicht von vielen Backup-Trauma Opfern gelernt hätte
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.
Um ehrlich zu sein habe ich Merge-Konflikte nur dann, wenn ich nicht aufpasse und vor changes im trunk nicht die Änderungen der branches zurückmerge. Ist mir nur einmal passiert bisher und da habe ich dann blöderweise tatsächlich ein feature wieder raus-gemerged (und sogar noch comitted). Aber so oft wie ich das mache ist das eine mal zwar einmal zu viel, aber inzwischen unter 1% und damit vernachlässigbar. Ehrlich gesagt finde ich das merging von
SVN richtig intelligent. Ich kann mir fast nicht vorstellen, das etwas da besser, geschweige denn *viel* besser sein soll. Und was ist 'hunk selection' und shelving? Bzw: Wie lange braucht man voraussichtlich, um das zu kapieren? *g*
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.
Es gibt nix geileres als im VS einen shortcut zu drücken und upzudaten & bauen. Genauso einen shortcut und ich habe ein Patch-File, welches ich an den Bugtracker-Task anhängen kann. Dafür die
IDE zu verlassen und das dann (schlimmstenfalls noch umständlich per Maus und context-Menü) extern zu machen ist, so oft wie ich das mache, eine massive Produktivitätseinschränkung. Genausa das switchen (bugfixes in den release-branches bis hin zum trunk 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.
Das klingt gut. Und wenn ich das richtig verstanden habe werden damit dann alle lokalen branches auch gleich mitgeschoben / aktualisiert? Ich habe also theoretisch auf dem zentralen server gleich alle branches, die irgendwo mal als feature-branch angefangen wurden? Wäre cool.
auch weil sie mit Lernen verbunden sind und damit die "Spurrinnen" in den Hirnen der Verweigerer allzu deutlich sichtbar machen würden.
Ich lege viel Wert auf Effizienz. Und ich sehe tatsächlich derzeit noch nicht wirklich den Effizienzgewinn durch einen Umstieg von
SVN (was derzeit alle Bedürfnisse abdeckt - und natürlich weil ich mich damit inzwischen recht gut auskenne
). Das heisst es müsste absehbar sein, dass der endgültige Effizienzgewinn durch einen Umstieg a) den Umstellungsaufwand und b) den anfänglichen Effizienzverlust wegen des umlernens in absehbarer Zeit ausgleicht und später übertrifft.