Revisionssystem einführen

[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

Sherlock

[DeddyH]

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

[DelphiBandit]

Zitat von ThYpHoOn:

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