Revisionssystem einführen

[ThYpHoOn]

Moin,

ich programmiere derzeit Beruflich in einer kleinen Softwareschmiede mit ca. 6 Programmierern. Wir haben im Prinzip mehrere von einander unabhängige Projekte + (gemeinsame) Library - wir arbeiten alle auf Delphi5 als IDE. Das "Merging" passiert derzeit händisch ohne feste Zeiten, dann wenn es eben für ein hotfix benötigt wird o.ä. in dem man in einem Netzwerkordner entsprechend die neuen Sourcen rein schiebt und diese dann per Vergleichsprogramm gemerged (das Tool was bei Total Commander dabei ist - ALT+D+V).

Das diese Methode Chaos mit sich bringt bzw. recht unproduktiv ist sollte eigentlich klar sein und ich habe mich privat auch schon des öfteren mit SVN sowie Mercurial beschäftigt. Da ich diesen Zustand schon länger bemängelt habe und seit knapp einem Jahr einen Vortrag über die Vorteile von SVN rumliegen habe der aber nicht angesehen werden möchte von den entscheidenden Leuten wollte ich Euch zum einen fragen was Ihr für Revisionssysteme produktiv (kommerziell) einsetzt und wie man die Chefs am besten dazu überredet bekommt so etwas einzuführen.


Greetz, ThY

[nachti1505]

Wir benutzen SVN... hatten aber auch die Erfahrung dass das Überzeugen der BigBosses sehr mühselig ist... man könnte denen vorrechnen, wieiviel Zeit für das Mergen drauf geht (was SVN bsp. alleine macht)!

[Bummi]

Argumente eine Chef gegenüber:
1.) Datensicherung in allen (Sub)Versionsständen
2.) quasi kostenlos
3.) automatisches Mergen mit Kontrolle wer wan was geändert hat.
4.) Je nach Einrichtung und Verwaltung Zugriff von jedem Platz der Welt
5.) Kunden können, wenn dies vereinbart ist immer die aktuellsten Sourcen ziehen
6.) Einfachere Verwaltung von Branches
7.) Zeit und dadurch Kostenersparnis

[Dezipaitor]

Man sollte nicht die Technik anpreisen, sondern die Lösung. Schreib doch mal auf, wieviele und welche Probleme es gibt und wie lange es jeweils braucht, so ein Problem im Durchschnitt zu lösen (SVN Konflikte, Mergekonflikte, Buildbreaks). Dann kannst du immernoch deine Lösung präsentieren in welcher Form (SVN) auch immer. Aber bedenke, dass Werkzeuge alleine keine Lösung sind. Dazu gehören immer auch Prozesse und letztendlich Menschen. Mitarbeiter müssen überzeugt werden (wenn auch von oben), dass dies auch sinnvoll ist, sonst rennt man gegen geschlossene Türen. Welche Prozesse/Vorgehensmodelle nutzt ihr überhaupt? Wasserfallmodell? Extreme Programming? Gibt es einen Ablauf für ein Fix-Commit-Test Zyklus? Wie wird getestet? uvm.

Letztendlich wird es DIE Lösung wohl garnicht geben. Es ist daher immer sehr sinnvoll die derzeitigen Strukturen und Abläufe in der Firma zu analysieren und darauf aufzubauen oder sie anzupassen. Grundlegend alles zu ändern ist sehr schwierig und kann auch nach hinten losgehen. Kleine Veränderungen, die gut propagiert werden helfen da oft vielmehr, besonders wenn die Leute begeistert mitmachen.

Weiterführende Literatur (habe ich auch):

Software Engineering, Jochen Ludewig et al., dpunkt.verlag
Lehrbuch der Softwaretechnik, Helmut Balzert, Spektrum
Abenteuer Software Qualität, Kurt Schneider, dpunkt.verlag
Managment von Softwareprojekten, Andreas Henrich, Oldenbourg

[ThYpHoOn]

Vielen Dank schon mal für Euer Feedback.

Das Vorrechnet ist denke ich mal vor allem für die BWL'ler wichtig, die wollen nun mal meistens nur die "nackten" Zahlen. Das kann ich aber auch nur rudimentär, ein Semester BWL auf der Uni hat mir gereicht, ich bin Programmierer ;) Aber ich denke für eine kleine Tabelle mit Zeit bzw. Arbeitsstunden die pro Woche drauf gehen sowie den Konflikten wenn z.b. unser "Maintainer" krank ist bzw. Urlaub hat (und die aktuellsten Sourcen auf dem Laptop auch physisch nicht vor Ort sind) hatten wir schon öfters die Situation keine aktuelle Version, trotz kritischer Bugs, zu deployen.

Ich werde es auch denke ich erst mal allgemein halten, muss aber dann sicherlich auch konkretisieren und entsprechende Vorschläge bringen, da ist es natürlich wie Dezipaitor schon sagte immer sehr individuell. Ich fokusiere im Moment Mercurial an, da es doch am einfachsten zu verstehen ist und vor allem mit TortoiseHG ein Windows-Gui gibt womit man recht intuitiv arbeiten kann (sofern man das System dahinter verstanden hat). Mal schauen ob ich mir noch ein passendes Software-Engineering Buch kaufe, danke für die Buchempfehlungen!


Greetz, ThY

[Phoenix]

Das Totschlagargument ist meiner Meinung nach die Sicherung und der Team-Weite Zugriff. Was, wenn einer im Team der kurz vor der Vollendung eines Features steht, plötzlich Krank wird (Autounfall, fällt für mehrere Wochen aus, Das Notebook im schlimmsten Fall im Auto dabei und nicht mehr rettbar)?

[hoika]

Hallo,

Totschlagargument
< Sicherung und der Team-Weite Zugriff >

Nein.

Das Totschlagargument ist die Nachvollziehbarkeit von Änderungen (changelog),
wer hat wann was geändert.



Heiko

[nachti1505]

Zitat:

Zitat von hoika (Beitrag 1056833)

Hallo,

Totschlagargument
< Sicherung und der Team-Weite Zugriff >

Nein.

Das Totschlagargument ist die Nachvollziehbarkeit von Änderungen (changelog),
wer hat wann was geändert.



Heiko

Erklär mal warum!? Weil diese Info haben wir bis dato noch nie gebraucht...! (Ok, statistisch ist es schön nachzusehen, wer wann welche Änderungen vorgenommen hat - aber inhaltlich waren diese Infos für uns eher unrelevant, da jeder Entwickler mehr oder weniger "seine" Module hat)

[shmia]

Man so ganz grundsätzlich:
Wer im Team programmiert und damit sein Geld verdient aber keine Versionsverwaltung hat,
der handelt fahrlässig unprofessionell!!
Das ist ungefähr so wie wenn ein Handwerker auf dem Bau ohne Elektrowerkzeug arbeiten würde. :wall:
Selbst Einzelkämpfer (Freelancer) sollten eine Versionsverwaltung verwenden.

Es stellt sich also nur noch die Frage, welche Software eingesetzt werden soll.
Wir verwenden z.B. Jedi-VCS und ich bin sehr zufrieden damit.

[HeikoAdams]

Das sehe ich ähnlich. Alleine schon aus dem Grund, das man schnell und relativ einfach zu einem funktionierenden Stand zurückkehren kann, falls man sich mal total verrannt hat, sollte man (auch als Einzelkämpfer) besser eine moderne Versionsverwaltung nutzen.

Um beim Thema zu bleiben: Ich kenne so ein Vorgehen, wie es der OP beschreibt, aus eigener Erfahrung und ich weiß, das es immer sehr "spaßig" war, falls mal 2 Entwickler gleichzeitig eine Unit bearbeiten wollten. Das ist dann im immer in wildem hin und her kopieren der Datei(en) geendet. Vielleicht wäre das auch ein Argument, das man für eine Versionsverwaltung ins Feld führen könnte.

[Sherlock]

Wir verwenden auch JEDI-VCS. Selbst wenn jeder Entwickler ein eigenes Projekt hat, so gibt es (bzw. sollte es geben) dennoch gemeinsame Units, in denen zB gemeinsame Komponenten liegen, oder irgendwelche andere Nützlichkeiten, die man immer wieder mal braucht. Auch das sollte nicht doppelt und dreifach auf irgendeinem Server verrotten oder schlimmstenfals in x verschiedenen Varianten die Entwicklung ausbremsen.

Eine Quellcodeverwaltung ist das A und O in der professionellen Softwareentwicklung, auch im Hinblick auf ein Qualitätsmanagement.

Sherlock

[Sir Rufo]

Ich finde es alleine deswegen schon cool, weil ich

a) ein paar eigene Bibliotheken habe, die ich mir zu meinen Projekten hinzuholen kann (svn:externals)

b) fremde Bibliotheken (soweit diese auf einem SVN liegen) auch

c) ich bei diesen Externals die Revision festschreiben kann, damit nicht irgendeine Änderung dort mein Programm zerfetzt (neuere Revisionen teste ich dann ganz gemütlich aus, zurre die wieder auf den aktuellen Build fest, oder springe in der Revision wieder zurück und warte bis die das gefixt haben)

Ja und das geht alles ohne wildes kopieren, downloaden und weiß der Geier ... sondern Rechtsklick - Aktualisieren und Projekt neu erzeugen fertig.

Externe Libs, die nicht via SVN bezogen werden können lege ich einfach bei mir ins SVN rein und ziehe dann von da.

Zu Jedi-VCS:

Damit bin ich angefangen. Was mich aber gestört hat, ist dass dort keine relative Ablage möglich ist. Habe ich ein Projekt unter "C:\Dokumente\PeterLustig\Weltherrschaft" dann muss das auf allen Rechner an diesem Ort liegen.

Bei SVN wird die Ordnerstruktur relativ betrachtet, was für mich erheblich besser ist.
Meine Projekte sind in meinem UserDoc-Verzeichnis (da gehören die meiner Meinung auch hin) bei allen anderen in Ihrem und mit SVN ist das auch kein Problem.

Darum bekam Jedi-VCS von mir die rote Karte.

[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 :D

Sherlock

[DeddyH]

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

[DelphiBandit]

Zitat:

Zitat von ThYpHoOn (Beitrag 1056813)

Das "Merging" passiert derzeit händisch ohne feste Zeiten, dann wenn es eben für ein hotfix benötigt wird o.ä. in dem man in einem Netzwerkordner entsprechend die neuen Sourcen rein schiebt und diese dann per Vergleichsprogramm gemerged..
..seit knapp einem Jahr einen Vortrag über die Vorteile von SVN rumliegen habe der aber nicht angesehen werden möchte von den entscheidenden Leuten wollte ich Euch zum einen fragen was Ihr für Revisionssysteme produktiv (kommerziell) einsetzt und wie man die Chefs am besten dazu überredet bekommt so etwas einzuführen.

Hört sich vom Ablauf etwas kontraproduktiv an :o Und fehlerträchtig, da man so sicher keine "abgeschlossene" Version zustande bekommt.

Erfahrungsgemäss ist es verlorene Liebesmüh einen Chef zu überreden etwas Neues einzuführen. Es hilft imho auch nichts, wenn mal wieder eine Version "buggy" gemerged wurde anzumerken, mit einer Versionskontrolle wäre das nicht passiert (obwohl es meist so ist!). Ich stimme mich bei solch weitreichenden Änderungen im Vorfeld hier bei uns mit meinen Kollegen ab, zeige Ihnen das vorher mal demonstrativ am lebenden Exempel in zwei virtuellen Maschinen usw.. Wenn alle an einem Strang ziehen, ist es meist einfacher gemeinsam beim Chef zu argumentieren "Wir brauchen unbedingt".

Und eigentlich könnt Ihr nur massenhaft Vorteile daraus ziehen. Kein Problem auf dem Rechner mal eben die Version xy wieder herzustellen oder mit dem Notebook mal eine Woche offline @home zu arbeiten. Das Zurückdrehen von SubVersion beschränkt sich auf die Löschung aller .svn Verzeichnisse und der Deinstallation des Clients - und Ihr seid wieder da wo Ihr jetzt seid. Da wollt Ihr nach einer gewissen Einarbeitungszeit aber sicher nie wieder hin!

Wir haben ebenfalls mit FreeVCS/JediVCS angefangen, wobei uns das Locking und wie schon angeführt die harten Pfade gestört haben. Seit einem 3/4 Jahr sind wir jetzt auf Subversion umgestiegen und sind super zufrieden damit.

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

Zitat von ThYpHoOn (Beitrag 1056965)

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:

Zitat von Rainer Wolff (Beitrag 1056969)

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:

Zitat von nachti1505 (Beitrag 1056987)

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:

Zitat von Sherlock (Beitrag 1056946)

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 :D

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 :mrgreen:

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

Zitat von Phoenix (Beitrag 1057082)

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:

Zitat von Phoenix (Beitrag 1057082)

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:

Zitat von ThYpHoOn (Beitrag 1057128)

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:

Zitat von Assarbad (Beitrag 1057173)

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:

Zitat von franktron (Beitrag 1057158)

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:

Zitat von ThYpHoOn (Beitrag 1057185)

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.

[Phoenix]

Zitat:

Zitat von Assarbad (Beitrag 1057090)

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:

Zitat von Assarbad (Beitrag 1057090)

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:

Zitat von Assarbad (Beitrag 1057090)

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:

Zitat von Assarbad (Beitrag 1057090)

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:

Zitat von Assarbad (Beitrag 1057090)

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:

Zitat von Phoenix (Beitrag 1057325)

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:

Zitat von Phoenix (Beitrag 1057325)

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:

Zitat von Phoenix (Beitrag 1057325)

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 :mrgreen:) 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:

Zitat von Phoenix (Beitrag 1057325)

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:

Zitat von Phoenix (Beitrag 1057325)

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:

Zitat von Phoenix (Beitrag 1057325)

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? :lol:

[USchuster]

Zitat:

Zitat von Assarbad (Beitrag 1057410)

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

Zitat von USchuster (Beitrag 1057435)

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/