Versionskontrolle - wie macht man sie richtig?

[mjustin]

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.