Revisionssystem einführen

[Sir Rufo]

Zitat von Sherlock:

Tja, gegen die rote Karte hilft der gute alte subst Befehl
Mit dem mappe ich mir meinen Delphi-Unterordner nach Z: und schon ist von da aus alles relativ

Sherlock

Klar und für externe JVCS-Projekte substed man dann auch lustig durch die Gegend und muss sich mit allen Beteiligten absprechen, wie denn gesubst wird. Nee danke, mit SVN geht es einfach so, auschecken und alle sind glücklich. Jeder darf wie er will ohne Rumgesubste

[s.h.a.r.k]

Ich sehe in der Versionsverwaltung auch nur Vorteile -- und da auch nur Vorteile von Git gegenüber dem SVN

Aber auch ich will meinen Kopf mal etwas zum qualmen bringen:
- Aufwand zur Einrichten eines Repos -> meist Admin notwendig
- Liegt der Server mal flach gibts Probleme bei der Synchronisierung. (klar, ich weiß, selbst hierfür gibts Lösungen)
- Fehlende Integrationen in IDEs. (Git in Delphi z.B.)

Bzgl. dem Autoversionierung: Wie erstellt das denn Kommentare? Ich habs aber nicht näher angeschaut!

Fazit: Es lohnt sich auf jeden Fall einzusetzen. Git kann auch ohne Server lokal versionieren (nur um ein wenig Werbung zu machen)

[Assarbad]

CVS ist doof, seine Merging-Fähigkeiten räudig, aber wir setzen es noch für diverse Dinge ein. CVS hat aber einen Vorteil, wenn man das gute alte System einsetzt: man kann die RCS-Dateien modifizieren, umbenennen, verschieben, ... ganz so daß bekannte Funktionen anderer VCS nachgestellt werden können. (Dies kann man aber auch als Nachteil ansehen ... am Ende ist es aber bei allen mir bekannten VCS und DVCS möglich Manipulationen in einem gewissen Rahmen vorzunehmen.)

SVN ist besser, aber meines Erachtens zeigen sich die Schwächen sobald man die neueren DVCS (Git, Mercurial, Bazaar) erstmal angetestet hat. Wir setzen SVN bei uns aber dennoch ebenfalls ein.

Mercurial ist derzeit mein Favorit, insbesondere weil Git zusammengeschustert ist (kein ursprüngliches einheitliches Konzept erkennbar und ein Mischmasch aus Skripten und anderen "Teilen") und Bazaar mir noch nicht erwachsen erscheint. Allerdings würde ich Bazaar fast ohne Zögern ebenfalls einsetzen. Git und Hg setzen wir in unseren Teams auch ein und ich weiß, daß das Virenlabor auch mit Bazaar arbeitet. Will heißen: alle funktionieren hinreichend gut. Ich kann nur empfehlen (so habe ich es gemacht) diverse VCS gegeneinander zu vergleichen und dabei die wichtigsten Fälle in der eigenen Umgebung durchzuspielen. Bei mir kam Mercurial als Sieger raus, aber ich bin mir sicher daß unter anderen Umständen auch Bazaar infrage käme.

SVN und CVS haben aber noch einen weiteren Nachteil. Sie belassen Dateien nicht so wie sie sind. Das erkennt man insbesondere bei sogenannten Textdateien. Ein echtes VCS darf einfach nicht mit den Daten herumspielen.

Aber nun zu dem Grund warum wir uns Zeit lassen eine Umstellung vorzunehmen.

Man kann CVS und Hg, bzw. SVN und Hg kombinieren. Klingt seltsam? Nunja, das Gute an DVCS ist, daß sie die komplette Versionshistorie bieten. Alle von ihnen kommen mit sehr guten Konvertierungswerkzeugen. Aber ich will auf etwas anderes hinaus. Man kann eine CVS/SVN Arbeitskopie auch zu einem DVCS-Repo machen, mit Hg mache ich dies sehr häufig. Dann hat man sozusagen ein "duales System". Hg bietet auch den Befehl addremove um einfach alle Dateien in einem Verzeichnis zum Repo hinzuzufügen. Dazu sollte man einzig alle CVS/SVN-Metadateien in .hgignore eintragen und dann "hg addremove" laufen lassen. Dann hat man alle Dateien auch in dem neuerstellten Hg-Repo und kann dort bequem und mit Hg arbeiten, branchen, mergen etc und später bei Zufriedenheit einen Zwischenstand in CVS/SVN einchecken. Eine komplett auf Hg basierende Lösung wäre zwar dennoch besser, aber egal ... so hat man lokal (oder auf beliebig vielen Rechnern) alle Vorteile von Hg, inklusive Queue-Management und muß dennoch nicht jemanden überzeugen auf ein anderes VCS zu wechseln.

[Phoenix]

Also ich kann mich persönlich bis jetzt noch nicht mit DVCSen anfreunden.

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?

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.

[Assarbad]

Zitat von Phoenix:

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.

Zitat von Phoenix:

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.

[ThYpHoOn]

Ich bin gerade dabei Testweise Mercurial nun auf meiner Workstation einzusetzen. Dies klappt soweit auch so wie ich es erwartet habe. Nur eine IDE-Integration wäre sehr nett. So wie z.b. die Integration von TortoiseSVN, da TortoiseHG allerdings einen "Overlay Icon Server" nutzt sieht das etwas kritisch aus. Ebenso habe ich kein TortoiseHG Menü wenn ich z.b. mit TotalCommander arbeite was dadurch schon eine deutliche Workflow-Unterbrechung mitsich zieht (Explorer auf machen, Ordner browsen, Rechtsklick, Commit). Hat da jemand einen Tipp für mich dies zu verbessern? (Sorry das ich hier etwas vom ursprünglichen Thema abkomme, war mir aber nicht Wert dafür ein neues aufzumachen)


Gz, ThY

[franktron]

Du kannst die doch unter Tools in der IDE ein paar Befehle einbauen die die HG.EXE aufrufen mit den nötigen Parametern.

[Assarbad]

Zitat von ThYpHoOn:

Ebenso habe ich kein TortoiseHG Menü wenn ich z.b. mit TotalCommander arbeite was dadurch schon eine deutliche Workflow-Unterbrechung mitsich zieht (Explorer auf machen, Ordner browsen, Rechtsklick, Commit). Hat da jemand einen Tipp für mich dies zu verbessern?

Meines Wissens nach gibt es von TotalCommander keine 64bit-Version, da er auch in BCB/Delphi geschrieben ist. Daher nehme ich mal an, daß es daran scheitert, daß du keine 32bit Shellerweiterung für TortoiseHg installiert hast, wenn du auf einem x64-Windows läufst.

[ThYpHoOn]

Zitat von Assarbad:

Meines Wissens nach gibt es von TotalCommander keine 64bit-Version, da er auch in BCB/Delphi geschrieben ist. Daher nehme ich mal an, daß es daran scheitert, daß du keine 32bit Shellerweiterung für TortoiseHg installiert hast, wenn du auf einem x64-Windows läufst.

Kann ich mir mal deine Glaskugel ausleiehen? Die ist verdammt gut Danke, genau daran lag es!

Zitat von franktron:

Du kannst die doch unter Tools in der IDE ein paar Befehle einbauen die die HG.EXE aufrufen mit den nötigen Parametern.

Stimmt, da hab ich wohl mal wieder zu kompliziert gedacht. Danke.

Ich werde dann morgen mal in gemütlicher Runde das Thema bearbeiten und hoffe auf ein positives Resultat.


Greetz, ThY

[Assarbad]

Zitat von ThYpHoOn:

Kann ich mir mal deine Glaskugel ausleiehen? Die ist verdammt gut Danke, genau daran lag es!

Nee, die muß sich jetzt erstmal ausruhen. Freut mich, daß der Hinweis geholfen hat.

Gruß aus dem Norden.