Revisionssystem einführen

[Phoenix]

Zitat von Assarbad:

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

Zitat von Assarbad:

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*

Zitat von Assarbad:

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.).

Zitat von Assarbad:

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.

Zitat von Assarbad:

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.

[Assarbad]

Zitat von Phoenix:

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

Gut gut. Gleiches kann aber auch noch zusätzlich bei DVCS machen

... der eigentliche Vorteil für mich bei Hg gegenüber waren nicht die ganzen tollen Features welche ich besprochen habe - die sind sozusagen Sahnehäubchen und Kirsche. Der eigentliche Vorteil war die Geschwindigkeit. Einen Teil davon könnte man im Übrigen auch in SVN mitnehmen, wenn die SVN-Entwicker sich von diesem bekloppten System verabschieden würden, bei dem die Metadaten (.svn Verzeichnisse) verstreut in der Arbeitskopie liegen. Das ist viel aufwendiger für das Dateisystem und daher langsamer. Aber die Krönung war echt wie lange es bei vielen Dateien dauert - insbesondere wenn kleine Dateien überwiegen. Da wir ohnehin schon ein riesiges SVN-Repo hatten, habe ich aus Verzweiflung irgendwann die ungenutzten Teile von bspw. Boost rausgworfen, weil die eine zusätzliche Verlangsamung bewirkten. Aber das ist noch immer sehr langsam gegenüber Hg. Dort hat man eben die gesamte Versionsgeschichte auf der lokalen Platte (und das Repo ist dennoch deutlich kleiner ...) wodurch die meisten Operationen tierisch schnell werden. Langsamer aber keineswegs vergleichbar langsam wie SVN, ist es bei Pull und Push.

Übrigens hat man sich zumindest bei Hg angewöhnt auch die coolen Seiten von bspw. Windows zu benutzen. Klone werden weitgehend über Hardlinks realisiert. Bis man also etwas ändert, wird kein zusätzlicher Platz verbraucht.

Zitat von Phoenix:

Und was ist 'hunk selection' und shelving? Bzw: Wie lange braucht man voraussichtlich, um das zu kapieren? *g*

Die meisten Funktionen (außer Queueing) sind bei TortoiseHg in der einen oder anderen Form verfügbar für Kommandozeilenabstinenzler

Shelving bedeutet, daß man Änderungen auf einen Stapel schiebt und danach in umgekehrter Reihenfolge wieder herunternehmen kann.

"Hunk selection" bedeutet, daß man innerhalb einer Datei bestimmte Änderungen eincheckt und andere noch so beläßt, daß sie nicht in der Versionshistorie erscheinen. Wenn man Legacy-Code pflegt und bspw. Bugfixes machen muß, ist das eine feine Angelegenheit.

Abgesehen davon gibt es noch Queueing:
Queueing habe ich in SVN noch nicht gefunden, aber ich lasse mich gern eines besseren belehren. Das ist, wenn man lokal Patches verwaltet und diese auf die von außen gezogenen Änderungen im Repository anwendet (bzw. durch die Software anwenden läßt). Gibt es auch bei Git, bei Bazaar bin ich mir jetzt nicht sicher, da das nicht zu meinem Vergleich damals gehörte. Benutzt wird das bspw. gern von den Leuten in der Linux-Kernel-Entwicklung. Ich bin mir aber sicher, daß du aus der Beschreibung (oder ggf. mit etwas Nachlesen) sofort ein paar Einsatzmöglichkeiten dafür in deinen Szenarien findest.

Übrigens Merge-Tracking wurde erst vor kurzem (1-2 Jahre?) in Subversion eingeführt. Bei den besprochenen DVCS ist es von Hause aus dabei und außerdem werden dort Verzeichnisse mitversioniert.

Zitat von Phoenix:

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.).

Dazu hat man zwei oder ggf. drei Bildschirme. Abgesehen davon mag es sein, daß man in einer "Nur-IDE-xyz"-Welt mit rosa Wölkchen (sorry ) sowas machen kann, bei mir kommt aber der gleiche Code auf diversen *nixen und in Windows mit verschiedenen VS und WDK/DDK zum Einsatz. Da geht es ohnehin immer nicht so glatt zu und man ist froh über jede Hilfe welche die darauf spezialisierten Tools bieten. Kurz, ich kann Hg auch ohne TortoiseHg ordentlich benutzen und muß dies oft genug auch tun - auf eine (vor allem überall gleich eingerichtete) IDE kann und will ich mich dabei nicht verlassen

Vielleicht habe ich mich auch etwas von dieser Unix-Philosophie anstecken lassen, daß es besser ist viele kleine Programme zu haben die für den jeweiligen Zweck perfekt geeignet sind und sich verknüpfen lassen, anstatt die eierlegende Wollmilchsau unter den Programmen zu haben.

Zitat von Phoenix:

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.

Also, für verzweigte Entwicklung gibt es bei Hg zwei Hauptstrategien. Die erste ist, diese als symbolische Namen anzulegen (so wie dies auch bei CVS/SVN geschieht). Dann wird bei einem Push alles mitgeschoben. Man "ist" dabei immer auf einem Zweig und muß den mit ggf. "hg update" ändern.

Die zweite Strategie ist es einen lokalen Klon anzulegen und auf diesem zu arbeiten. Sobald man dann eine Änderung hat die hineingehen soll, kann man (ggf. mit hg rebase) zu dem lokalen Quelrepo schieben und von dort ggf. weiter. Ich persönlich bevorzuge die zweite Strategie, benutze die erste aber bspw. für Release-Branches.

Zitat von Phoenix:

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 ).

Keine Angst, ich will dich nicht bekehren, denn was hätte ich davon? Wenn SVN deinen Anforderungen genügt, bleib dabei und gucke dir ggf. im Rahmen von Freizeit-Projekten mal die anderen VCS-Lösungen an. Ich kenne bspw. eine Menge Leute die auf Git schwören. Meinetwegen sollen sie doch - und meinetwegen sollen sie versuchen mich zu bekehren. Ich habe den Vergleich gemacht und werde den irgendwann nochmal auffrischen und derzeit ist mein Favorit eben Hg

Zitat von Phoenix:

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.

Absolut. Und wie sich ja nun herauskristallisiert hat, haben wir verschiedene Anforderungen an unsere VCS-Lösungen. Ich finde das absolut legitim.

Übrigens: das regelmäßige Einchecken (vorzugsweise mehrfach am Tag beim aktiven Entwickeln) ist absolut keine Selbstverständlichkeit bei vielen Entwicklern. Da kotze ich dann immer ab, wenn sie mir erzählen, daß sie an einem Feature oder Bugfix gewerkelt haben und keine Zwischenstände sichtbar sind.

Mein Tip:
Wenn dir dein Arbeitgeber die Zeit gibt oder du sie dir eigenverantwortlich nehmen kannst um sowas mal zu testen, probiere es anhand eures SVN-Repos. Alle DVCS bieten hervorragende Konvertierungswerkzeuge (wobei einige als Plugins kommen). Auch inkrementelle Konvertierung ist drin, so daß mit ein wenig anfänglichem Aufwand selbst einem gemischten Betrieb nichts im Wege stehen sollte. Sobald du konvertiert hast, probiere einfach die üblichen Funktionen welche du bei SVN benutzt einmal aus. Die meisten Basisfunktionen sind beim Namen geblieben. Nur beim Einchecken muß man sich bewußt sein, daß dies nur lokal geschieht. Um es an ein (bspw. per Konvention zentrales) Repo zu schicken muß man Push benutzen. Wenn du das mal ausprobiert hast, weißt du jedenfalls für dich, daß du beruhigt und ohne Reue SVN weiterbenutzen kannst ohne das Gefühl zu haben etwas zu verpassen. Oder du stellst fest, daß etwas dran ist und leitest ggf. eine sanfte Migration ein.

Nachtrag:
Ach und übrigens: CVS war in meinen Vergleichen bisher noch immer deutlich schneller als SVN. Vielleicht hat da jemand bei "besser als CVS" gedacht, daß sich alle Werte erhöhen müßten?

[USchuster]

Zitat von Assarbad:

... der eigentliche Vorteil für mich bei Hg gegenüber waren nicht die ganzen tollen Features welche ich besprochen habe - die sind sozusagen Sahnehäubchen und Kirsche. Der eigentliche Vorteil war die Geschwindigkeit. Einen Teil davon könnte man im Übrigen auch in SVN mitnehmen, wenn die SVN-Entwicker sich von diesem bekloppten System verabschieden würden, bei dem die Metadaten (.svn Verzeichnisse) verstreut in der Arbeitskopie liegen. Das ist viel aufwendiger für das Dateisystem und daher langsamer. Aber die Krönung war echt wie lange es bei vielen Dateien dauert - insbesondere wenn kleine Dateien überwiegen.

Die SVN Entwickler haben sich inzwischen davon verabschiedet. Working Copy Next Generation ist eins der Keyfeatures des hoffentlich bald erscheinenden 1.7 Releases. Laut aktueller Roadmap soll es im Dezember released werden, da dies jedoch bereits mehrfach verschoben wurde glaube ich noch nicht daran auch wenn der aktuelle Entwicklungsstand bereits seit einigen Wochen nur noch ein .svn Verzeichnis pro Working Copy hat.

[Assarbad]

Zitat von USchuster:

Die SVN Entwickler haben sich inzwischen davon verabschiedet. Working Copy Next Generation ist eins der Keyfeatures des hoffentlich bald erscheinenden 1.7 Releases. Laut aktueller Roadmap soll es im Dezember released werden, da dies jedoch bereits mehrfach verschoben wurde glaube ich noch nicht daran auch wenn der aktuelle Entwicklungsstand bereits seit einigen Wochen nur noch ein .svn Verzeichnis pro Working Copy hat.

Immerhin. Danke für den Hinweis. Zumindest als dogmatisch zentrale Alternative (ich meine das nicht abwertend, sondern als Vorteil in Teams bei denen die Mitglieder ansonsten auf den Änderungen sitzen würden, was andere Probleme verursacht) könnte SVN dann durchaus wieder attraktiver werden. Leider heißt es bei Einsatz von Debian (als Server) noch zwei Jahre warten, da die sehr konservativ mit der Aufnahme neuer Features/Versionen sind.

Nachtrag: nett nett ... http://svn.apache.org/repos/asf/subv...s/wc-ng/design

[Assarbad]

Übrigens, gerade erst gefunden: VisualHg -> http://visualhg.codeplex.com/