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.