Versionskontrolle - wie macht man sie richtig?

[worker]

Hallo,

auch wenn jetzt etwas mehr Text folgt, so geht es meiner Meinung doch jeden Entwickler etwas an. Lasst Euch von der Textmenge also bitte nicht abschrecken.

Bezugnehmend auf diesen Beitrag möchte ich die Frage in den Raum stellen, wie man korrekte (revisionssichere) Versionskontrolle bei mehreren Projekten durchführt.

Bei einem Projekt dürfte das Ganze keine Schwierigkeit darstellen.
Man hat seine eigenen Sourcen, Fremdkomponenten etc., meinetwegen strukturiert in mehreren Verzeichnissen, und verwaltet diese mit einem x-beliebigen Versionskontrollsystem (VSS, SVN, JVCS ...).
Ist eine Version fertiggestellt, so wird dieser Stand inkl. aller Sourcen (auch der Fremdsourcen, da im gleichen Projekt) festgehalten (gestempelt, markiert).
Bei Bedarf kann so revisionssicher auf alle festgehaltenen Versionen zurückgegriffen werden.

Was ist aber nun, wenn man mehrere Projekte hat, die auf gemeinsam genutzte Sourcen (Abhängigkeiten, Externals) zugreifen, und man Redundanzen vermeiden will?

Beispiel:
Ich habe die Projekte A, B und C.
Alle diese Projekte greifen auf allgemeine Sourcen D zu. Hierin gibt es verschiedene Units, welche Funktionen verschiedener Themengebiete beinhalten, zB. Stringfunktionen, Filefunktionen, Systemfunktionen...

Die Verzeichnisstruktur sieht folgendermaßen aus:

-Projekte
--A
--B
--C
--D

Gehen wir mal von SVN aus, so verfügt jedes der Projekte (auch die allgemeinen Sourcen D sind ein Projekt) über ein eigenes Repository.

Nehmen wir an, die allgemeinen Sourcen seien ersteinmal statisch.
Wir entwickeln unsere Projekte A, B und C und halten einzelne Versionen fest, bspw. von jedem Projekt 1.0.0, 1.1.0 und 1.2.0.
Wichtig ist nun, dass die allgemeinen Sourcen D von den anderen Projekten verwendet, bei der Markierung derer aber nicht berücksichtigt werden, da sie sich ja nicht im gleichen Arbeitsverzeichnis und somit auch nicht im gleichen Repository befinden (Vermeidung von Redundanzen).

Irgendwann sind Anpassungen der allgemeinen Sourcen notwendig, die wir mit der Version 1.3.0 in den Projekten A, B und C umsetzen.

Wir entwickeln weiter und landen irgendwann bei 1.8.0.

Nun meldet ein Kunde einen Fehler in Version 1.2.0, den wir unbedingt in dieser Version (1.2.1) beheben müssen, da der Kunde nicht auf 1.3.0 und höher updaten kann/will.

So, wir rufen nun also unsere Version 1.2.0 ab. Wenn wir diese nun kompilieren, so wird natürlich der aktuelle Stand der allgemeinen Sourcen gezogen und nicht der, der eigentlich zu Version 1.2.0 gehört.

So - hier liegt nun der Casus Knacktus. Wie verwaltet man die allgemeinen Sourcen richtig, um einerseits Redundanzen zu vermeiden, andererseits diese aber irgendwie bei der Markierung referenzierender Projekte zu berücksichtigen?

Möglichkeiten der IDE:
Die IDE des Visual Studios bietet die Möglichkeit, referenzierte Dateien beim Linken in das Projekt zu kopieren.
Diese befinden sich dann eben im gleichen Arbeitsverzeichnis und somit auch im gleichen Repository und werden mit markiert.
Alles lecker also.
Delphi bietet sowas leider nicht.

Möglichgkeiten des VCS:
SVN bietet die Möglichkeit, 'externals' in die Arbeitskopie zu integrieren. Dabei wird beim Abrufen der Sourcen eine Kopie der Externals in das Projektverzeichnis geholt. Nachteile wurden von mjustin in dem o.g. Beitrag erwähnt.
Weiterer Nachteil aus meiner Sicht: die 'externals' lassen sich nur in Form eines Repositories angeben, d.h. es würden sämtliche Dateien des Repositories der allgemeinen Sourcen in das Projektverzeichnis kopiert obwohl evtl. nur eine Davon benötigt wird.

Meine Frage ist nun: wie lässt sich das lösen? Wie macht Ihr das?

Ich würde mich freuen, wenn sich an dieser Diskussion viele Leute beteiligen, da dieses Thema wohl jeden Entwickler etwas angeht.

[hazard999]

Schon mal von einem Branch gehört?

[Die Muhkuh]

Im Branch liegen experimentelle Entwicklungen oder Features, die getrennt von der Hauptversion entwickelt werden und erst später wieder zurück geführt werden, das behebt sein Problem nicht.

[Sherlock]

Es geht um von mehreren Projekten genutzte Units? Ich habe in der Hinsicht keine Probleme bei JVCS bemerkt, das funktioniert automagisch - auch das erzeugen alter Versionsstände.

Sherlock

[hazard999]

Naja,

wir machen das so:

Der trunk ist die Hauptentwicklungsversion.

Wenn ein neues Release (Wartung oder Featurerequest) fällig ist wird ein Branch gezogen.

Sollte ein Bug behoben werden in einem Release, dann wird der dort ausgebessert und
nach oben (also in die neueren Branches bis zum trunk) gmerged.

Würde das Problem also beheben, denke ich.

Und jeder Branch ist immer auscheckbar.

Ach ja, jeder Build wird bei uns getagt. SVN fährt ja unterschiedliche Versionsnummern pro File.

[worker]

@hazard999

Grundlegendes Versionsmanagement ist nicht das Problem; ich arbeite auch mit trunk, tags und branches.
Darum geht es aber nicht.

Es geht darum, dass allgemeine Sourcen D, die sich nicht im Projektverzeichnis A befinden, da sie von mehreren Projekten (A, B, C) genutzt werden und nur an einer zentralen Stelle, nämlich dem Repository von D, verwaltet werden sollen, nicht markiert werden, da sie sich eben nicht im gleichen Repository befinden wie das Projekt A.

Ich habe das doch ausführlich erläutert :)

[Tyrael Y.]

Ihm geht es darum, allgemeine Daten, die sich in einem anderen Repository befinden, zu einer gelabelten Version zu Referenzieren.

A
A.1 - D.2
A.2 - D.4

B
B.1 - D.1
B.2 - D.4

C
C.1 - D.3
C.2 - D.4


D
D.1
D.2
D.3
D.4


Edit: roter Kasten, aber ich poste trotzdem mal

[worker]

Zitat:

Zitat von Tyrael Y.

Ihm geht es darum, allgemeine Daten, die sich in einem anderen Repository befinden, zu einer gelabelten Version zu Referenzieren.

Genau darum geht es :thumb:

@Sherlock
Hört sich erstmal gut an. Allerdings kann ich mir noch nicht so richtig vorstellen, dass das JVCS wirklich weiß, das es Dateien aus anderen Projekten festhalten muss - woher soll es das wissen?

[mjustin]

Zitat:

Zitat von worker

Weiterer Nachteil aus meiner Sicht: die 'externals' lassen sich nur in Form eines Repositories angeben, d.h. es würden sämtliche Dateien des Repositories der allgemeinen Sourcen in das Projektverzeichnis kopiert obwohl evtl. nur eine Davon benötigt wird.

Man kann mit svn:externals auch einzelne Unterverzeichnisse des Repositories einbinden, und dabei auch z.B. auf fremde, im Internet liegende Repositories zugreifen. Beispiel:

[code]$ svn propget svn:externals calc
third-party/sounds http://sounds.red-bean.com/repos
third-party/skins http://skins.red-bean.com/repositories/skinproj

http://svnbook.red-bean.com/en/1.0/ch07s03.html
bzw.:
http://www.open.collab.net/community...externals.html



Zur Problemlösung:

a) feste Verzeichnisse für externe / zentrale Libraries anlegen

C:\Delphi\Skinlib-1.0
C:\Delphi\Skinlib-1.1
C:\Delphi\Skinlib-1.2
...
C:\Delphi\MathLib-2.0
C:\Delphi\MathLib-2.1
C:\Delphi\MathLib-2.2
...

(der Rootpfad C:\Delphi kann in Delphi über eine selbstdefinierte Variable vom Entwickler festgelegt werden)

Der Build kann mit einem Tool wie Apache Ant automatisiert werden, wobei in einer build.properties die Pfade zu den Libraries hinterlegt werden. Dieses Buildskript wird dann mit der jeweiligen Version des Produkts versioniert. Mit Ant kann man auch über Makros alle Projekte einer Verzeichnisstruktur durchlaufen und bauen, ausserhalb der IDE (und mit einer für alle Entwickler identischen Konfiguration des Compilers und aller sonstigen Tools). In wenigen Minuten hat man dann nach dem Auschecken "auf Knopfdruck" ein Dutzend Anwendungen kompiliert und Unittests ausgeführt.

Vorteil: Trennung der Verzeichnisse für Projekte und zentrale Libraries, Platzeinsparung wenn man sehr vielen Projekte hat die diese zentrale Libraries benötigen, funktioniert ohne Einsatz von svn:externals

b) abhängige Libraries komplett in den Projekten mit einbinden

Ebenfalls ohne svn:externals, sehr einfach zu nutzen (beim Checkout holt man das gesamte Projekt in einem Schritt.) Nachteil: Änderungen an den zentralen Libraries müssen dann einzeln in alle Projekte übernommen werden

c) svn:externals mit Angabe einer bestimmten Revision

Die zentralen Libraries werden getrennt verwaltet, aber im Projekt als Unterverzeichnis eingebunden, können damit komplett mit dem Projekt ausgecheckt werden. Durch die Angabe der Revision ist garantiert, das beim Auschecken genau der passende Stand der zentralen Libraries verwendet wird. Problematisch ist bei svn:externals aber manches, z.B. wenn die URLs nicht mehr gelten (Repository zieht um oder ist nicht erreichbar), oder wenn man aus dem externals Verzeichnis nur eine einzelne Datei benötigt (man kann nur komplette Pfade angeben)


Mein Favorit zur Zeit ist Variante A in Verbindung mit einem darauf abgestimmten Buildskript (mit Apache Ant). Auch nach einem Auslagern alter Versionen der zentralen Libraries auf Speichermedien kann man sich anhand der Pfadangaben in den Buildskripts leicht wieder die "passende" Build-Umgebung zusammenbauen.

[kalmi01]

Moin moin,

ich entwickle in mehreren VM-Umgebungen. Einzelne, kleinere Änderungen verwalte ich innerhalb einer VM. Wenn neue Tools installiert werden, mache ich ein Backup der VM.
Auf diese Weise kann ich jederzeit und sicher auf einen funktionierenden (älteren) Software- und Release-Stand zurück gehen.

[Tyrael Y.]

Ich meine man kann bei SVN Repositories miteinander verlinken (Repository A, B)

Ab diesem Zeitpunkt führt ein Labeln bei A automatisch zu einem Label bei B.
Holt man sich von A den gelabelten Stand, dann wird von B der dazugehörige Stand auch automatisch geholt.

Ich meine das verlinken geht auf jeden Fall, gemacht habe ich es leider noch nicht, so daß ich dir die genauen Schritte nicht sagen kann.

[Sherlock]

Zitat:

Zitat von worker

Zitat:

Zitat von Tyrael Y.

Ihm geht es darum, allgemeine Daten, die sich in einem anderen Repository befinden, zu einer gelabelten Version zu Referenzieren.

Genau darum geht es :thumb:

@Sherlock
Hört sich erstmal gut an. Allerdings kann ich mir noch nicht so richtig vorstellen, dass das JVCS wirklich weiß, das es Dateien aus anderen Projekten festhalten muss - woher soll es das wissen?

Zum einen weiß das JVCS, daß eine Unit bereits von einem anderen Projekt verwendet wird, nur dadurch, daß die Unit haargenau an der gleichen Stelle liegt ;). Zum anderen sieht das dann zum Beispiel für eine gesharete Unit so aus:

Zitat:

MyLib_TLB.pas
===============

8 entries.

Shared by project | Project ID
------------------- | ----------
activefoochart.dpr | 114
activefoogrid.dpr | 132
chbar.dpr | 122
foocontainer.dpr | 112
foo_plugger_.dpr | 139
foobarchart.dpr | 143
foobazpr.dpr | 135
foobarbazdpr.dpr | 131

Source: Oracle8 Native Server V 1.00 on 192.168.100.8 [2106]
JEDI VCS 2.4.0.700 © 2002-2006 JEDI VCS (http://jedivcs.sourceforge.net) - 05.02.2009 11:05:37

Unsere Vorgehensweise beim Wiederherstellen einer älteren Version ist (weil wir noch nicht auf die neuere JVCS Version umgestiegen sind, die das besser regelt) einfach die Dateiversionen zum gewünschten Datum zurückzuholen. Funktioniert einwandfrei. Wenn das dann durch ist, kann man mit dem aktuellsten Stand synchronisiern und alles ist so wie vorher. Änderungen im alten Release werden in der Regel von Hand in die neue Version übertragen, was aber in unserer unbegründeten Urangst vor automatischen Mergetools begründet ist.

Sherlock

[worker]

@mjustin: Deine Vorgehensweise hattest Du ja schon geschildert - danke trotzdem, dass Du Dir nochmal die Mühe gemacht hast :)
Dennoch finde ich bei Deinen Vorschlägen leider keinen, der mich auf Anhieb zufrieden stellt :(
Über Möglichkeit A werde ich allerdings nochmal etwas genauer nachdenken :)

@kalmi01
Auch wenn Speicherplatz heutzutage kein Thema mehr ist, aber das finde ich doch ein bissel extrem - dafür aber sicherlich die einzige Möglichkeit, wirklich absolut revisionssicher zu sein (auch was die VCL angeht) ;)

@Tyrael Y.
Schön wäre das. Habe diese Möglichkeit bisher allerdings noch nicht gefunden. Oder meinst Du svn:externals?

@Sherlock
Hört sich in der Tat super an - allerdings bekomjme ich gerade nichtmal den JVCS Server mit mySQL ans laufen... Ein Trauerspiel. Der Server startet einfach nicht. :wall:

[Sherlock]

Zur Installation mit mysql kann ich leider nix sagen, aber auf Posts in der Newsgroup reagiert man ziemlich schnell.

Viel Erfolg!

Sherlock

[Tyrael Y.]

Ja, ich meine schon, daß es mit svn:externals geht.

kleine Info

..sollte man auch beachten!

[worker]

@Tyrael Y.
Dann fällt das vorerst aus ;) Dennoch danke.

@Sherlock
So, der Server läuft, und ich habe das Ganze mal getestet.
Auf den ersten Blick sieht es gut aus, auf den zweiten Blick gibt es da ein kleines Problemchen:

Ich habe ein shared modul in zwei Projekte eingebunden.
Nun stemple ich Projekt A auf Version 2.0.
Das shared modul wird nun ebenfalls auf 2.0 gestempelt.

Irgendwann hat dann auch Projekt B Stand 2.0 erreicht und wird nun ebenfalls so gestempelt.

Und da ist das Problem.
JVCS erkennt, dass das shared modul früher schon einmal mit 2.0 gestempelt worden ist, und stellt mich vor die Wahl:

• Entweder ich stemple das shared modul nun, oder
• ich stemple es nicht.

Wenn ich es stemple, dann geht mir der Stempel 2.0 des shared moduls von Projekt A verloren. Das bedeutet, rufe ich später die gestempelte Version 2.0 von Projekt A ab, so erhalte ich nicht die Version 2.0 des shared moduls von Projekt A, sondern die von Projekt B.

Stemple ich nicht, so fehlt mir der Stempel 2.0 für Projekt B.

Die einzige Alternative wäre, für die Bezeichnung des Stempels nicht nur eine Versionsnummer zu vergeben, sondern auch den Namen des Projektes.
Das wird natürlich irgendwann mal extram unübersichtlich im Label-Manager.

Irgendwie ist das alles Käse *grml*


Und nein, ich glaube noch immer nicht, dass diejenigen, die sich bisher hier zu Wort gemeldet haben, die einzigen sind, die Versionsmanagement betreiben.
Ist das so ein großes Geheimnis, oder warum melden sich nicht die Power-User (5000+ Posts) dieses Forums mal zu Wort? :gruebel:

[Sherlock]

Das mit den vielen Stempeln ist zwar unschön, aber naja...im Prinzip egal. Die haben ja den Sinn, daß man damit per Label eine Version hergestellen kann. Wenn Du gar nicht labelst, kommst Du wie gesagt auch nur per Datum hin, d.h. Du checkst eine Version ein und als CheckIn-Kommentar gibst Du eben noch mit an, daß dies ein Release der Version XY ist, in der Version-History kannst Du eben dann sehen, wann die Version eingecheckt wurde, und nach datum zurück holen. Klingt wirr und kompliziert, aber die Oberfläche macht es einem einfach. Hast Du mal im Manual geschaut, was da zu dem Thema geschrieben wird?

Sherlock

[worker]

Zitat:

Zitat von Sherlock

Das mit den vielen Stempeln ist zwar unschön, aber naja...im Prinzip egal. Die haben ja den Sinn, daß man damit per Label eine Version hergestellen kann.

Hätte ich die Möglichkeit, ad hoc einen Stempel zu vergeben, also ohne den Label-Manager, dann wäre das ja auch in Ordnung.
Oder wenn der Label-Manager die Labels je Projekt verwalten würde. Dann hätte ich immer schon meine Labels nur für das aktuelle Projekt -> perfekt.

Das mit der Uhrzeit... hmm.
Wird beim Einchecken auch die Eincheckzeit der Dateien gesetzt, die gar nicht geändert worden sind?
Und dann müsste man sich ja zusätzlich noch irgendwo notieren, um welche Uhrzeit man welche Version eingecheckt hat :gruebel:
Irgendwie alles nicht so das Wahre - echt zum verzweifeln :cry:

[Sherlock]

Du brauchst nicht die Zeiten von ungeänderten Dateien notieren, ändern oder sonstwie. Die Abfrage ist einfach jüngste Dateien vor Datum/Zeit.

Sherlock

[Pfoto]

Hallo Worker,

ich bin gerade dabei mir Subversion zu installieren
und stelle mir auch die Frage, wie ich zu einem *wirklichen*
früheren Versionstatus zurückkommen kann (also auch den
Status der ganzen Komponenten)

Eben habe ich dieses PlugIn für Delphi gefunden:
SourceConneXion

Zumindest heißt es in den Features:
"Share files from other projects from inside the IDE."

Vielleicht trägt das etwas zur Lösung bei.

Gruß
Jürgen

[hoika]

Hallo,

genau über das Problem bin ich im SVN gestolpert.
Ich arbeite hier noch mti einer uralten PVCS-Verison.

Dort kann ich Unter/Unter/Unter-Projekte bilden.

Ich habe also nur ein Rootprojekt,
jedes Programm ist ein Unterprojekt.

Version-Tags z.B. ver_prog_1.1 oder ver_prog1.2
werden immer ab dem Root-Projekt gesetzt.


Heiko

[worker]

@Sherlock
Ich will keine Zeiten von ungeänderten Dateien notieren; ich fragte, ob beim Einchecken des Projektes auch die Eincheckzeit der Dateien aktualisiert wird, die gar nicht verändert worden sind. Denn es müssen ja alle Dateien die gleiche Zeit haben; ansonsten habe ich ja kein Kriterium auf dessen Basis ich eine alte Version abrufen kann. Was ich aber machen muss -> ich muss die Zeiten notieren, zu welcher ein bestimmtes Release kompiliert wurde. Ansonsten weiß ich ja später nicht, welche Zeit zu welcher Version gehört ;)

@Pfoto
Danke, werde mir den Link mal ansehen

@hoika
Genau das ist das Verfahren, das ich für JVCS präferieren würde; den Programmnamen in das Label mit aufnehmen.

___________________


Aber ich glaube, dass ich jetzt etwas ganz anderes machen werde:
Ich lasse als Pre-Build-Aktion einfach eine Batch-Datei ausführen, die alle genutzten Externals ins Projektverzeichnis\Externals kopiert.
Die Pfade muss ich dann halt manuell in die Batch-Datei eintragen; aber was solls... So oft macht man das ja nun auch nicht.
Ist quasi das, was die Visual-Studio-IDE auch macht.

So habe ich zwar redundante Daten in den Repositories, muss Änderungen aber trotzdem nur an einer Stelle machen.

Vielleicht bietet SVN ja irgendwann mal die Möglichkeit, externals auch auf einzelne Dateien zu setzen und nicht nur auf Verzeichnisse.
Oder vielleicht bietet die Jedi VCS ja irgendwann mal die Möglichkeit, das Labels auf shared modules nur i maktuellen Projekt gestempelt werden und nicht global; oder zumindest das Freitexte als Label eingegeben werden können, ohne den Umweg über den Label-Manager.