Revisionssystem einführen

[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

[DeddyH]

[OT] Eine neue Form der Relativitätstheorie [/OT]

[ThYpHoOn]

Jedi-VCS ist aber "nur" ein VCS und kein DVCS. Ich tendiere im Moment eher zu einem DVCS wie Git oder Mercurial da man dort deutlich flexibler ist und vor allem das Problem des "Maintainer" relativ gut lösen kann (das eben nicht alle direkt auf den main/stable committen). Dies war bislang auch immer eine der Hauptargumente gegen ein VCS, dass dort jeder einfach alles committen kann und wir dadurch Instabilität bekommen würden. Wenn man nun jedoch einfach sein Repository hat kann der Maintainer einfach alle Änderungen aus den verschiedenen repos pullen und die dann entsprechend bewerten und in den Mainrepo einfließen lassen. Arbeitet hier jemand mit einem DVCS? Oder alle "nur" mit SVN/VCS?

Ich werde wohl auch einfach mal anfangen meine Änderungen Lokal in ein Mercurial Repo zu packen und somit ein zumindest für mich sehbares Resultat zu haben und dieses dann mit meinen Arbeitskollegen weiter vertiefen zu können. Ich denke auch das man hier nur gemeinsam im Team eine Lösung präsentieren kann, vor allem weil sich eben dann auch alle anpassen müssen, wobei das bei unserem recht kleinen Team noch nicht so schwierig sein sollte.


Greetz, ThY

[DelphiBandit]

Zitat von ThYpHoOn:

das eben nicht alle direkt auf den main/stable committen)

Der Main (trunk) ist bei uns nie der stable, sondern der Entwicklungszweig wo die aktuelle Version weiterentwickelt wird. Direkt vor dem Release wird diese dann in eine getaggte Version überführt - die getestete Lieferversion. Sollte es daran dann noch Änderungen geben (Patches), dann kann man diese ggf. aus dem trunk dazumergen. Da es meist Kleinigkeiten sind ist es auch kein Ding die in beiden Pfaden nachzuziehen.

Und man kann mit dem Rechtesystem von SubVersion sehr wohl verhindern, dass in den tags, welches aus Sicht von SVN auch nur ein Verzeichnis ist, von jedem rumgeschrieben werden darf. Somit kannst Du das einem Verantwortlichen übertragen Versionen abzuschliessen. Das geht sogar so weit, dass Du bestimmten Kollegen bestimmte wichtige Unterverzeichnisse im Programm verbieten kannst, damit die nichts "kaputt committen".

Hab Deinen Post jetzt noch 2 x gelesen und denke ich verstehe jetzt auch den Unterschied auf den Du abzielst. Dann brauchst Du für den Maintainer aber wohl jemanden der genau abschätzen kann, was er dort zusammenwirft ohne dass andere Stellen darunter leiden. Dafür das Endprodukt für das tagging vorzubereiten haben wir einen festen Testablauf des Programmes und eine QS.

[Rainer Wolff]

Für mich stellt sich nur noch die Frage, was denn gegen ein Versionssystem spricht?

Es gibt genug freie und gute Lösungen, mit TortoiseSVN & Co. ist der Umgang damit ganz bequem und die technisch-organisatorischen Vorteile wurden ja bereits erwähnt.

Ich finde es vor allem auch sehr gut, zu wissen, dass eine gültige Version auf dem Server liegt und ich habe nicht mehr 25 Versionen auf 5 Rechnern und 20 Verzeichnissen.

Ansonsten könnte ich mir nicht mehr vorstellen, je nochmals ohne Versionssystem zu arbeiten.

Rainer

[nachti1505]

Zitat von Rainer Wolff:

Für mich stellt sich nur noch die Frage, was denn gegen ein Versionssystem spricht?

Auch wenn es blöd klingt und NICHT meine Meinung wiederspiegelt, der Mehraufwand für soetwas spricht immer dagegen (wenn man vom Nutzen noch nicht überzeugt ist, fällt demnach auch die Aufwand/Nutzen-Rechnung flach)! Zumal der Mensch als Gewohnheitstier nicht unbedingt permanent nach Neuem strebt!

[BUG]

Zitat von nachti1505:

Auch wenn es blöd klingt und NICHT meine Meinung wiederspiegelt, der Mehraufwand für soetwas spricht immer dagegen (wenn man vom Nutzen noch nicht überzeugt ist, fällt demnach auch die Aufwand/Nutzen-Rechnung flach)! Zumal der Mensch als Gewohnheitstier nicht unbedingt permanent nach Neuem strebt!

Das könnte Hemmschwellen bei nicht Überzeugten abbauen: Autoversionierung

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