Vendor Branches
Einbindung von fremder Software
Vendor Branches dienen dem Zweck, den Sourcecode Dritter in das Versionsmanagement einzubinden. Der Lieferant dieses Sourcecodes wird als Vendor (Verkäufer) bezeichnet. Weshalb sollte man Sourcecode Dritter in das eigene Versionsmanagement aufnehmen? Ein Fall könnte sein, dass man ein eigenes Projekt in Teilen auf einem Open Source Projekt aufgebaut hat und auch dieses laufend weiter entwickelt wird. Um die eigene Arbeit und die Änderungen an dem Open Source Projekt zusammen zu führen, bietet sich Subversion natürlich an. Ein anderer Fall könnte sein, dass man Programmbibliotheken eines anderen Herstellers einsetzen möchte und diese in Form von Sourcecode ausgeliefert werden. Somit kann man die ausgelieferten Bibliotheken selbst verändern. Irgendwann wird der Hersteller eine neue Version seiner Bibliotheken ausliefern. Auch in diesem Fall bietet es sich an, Vendor Branches einzusetzen und Subversion zur Zusammenführung und Verwaltung des Sourcecodes zu verwenden.
Gegenüber extern verwalteten Bibliotheken haben Vendor Branches den Vorteil, dass einerseits das Versionsmanagementsystem zur Zusammenführung eigener Änderungen und Änderungen durch den Anbieter verwendet werden kann und dass andererseits keine externe Konfiguration von Bibliotheken durch den Entwickler notwendig ist. Alle notwendigen Bestandteile der Bibliothek werden ganz einfach zusammen mit dem eigenen Sourcecode aus dem Repository ausgecheckt.
Die generelle Arbeitsweise
Im Gegensatz zu anderen Versionsmanagementsystemen wie CVS braucht man zur Verwaltung von Vendor Branches mit Subversion keine neuen Konzepte oder Mechanismen einführen. Es ist alles schon da. Als Beispiel sei die Bibliothek TextLib angenommen, die als fremde Software in ein eigenes Softwareprojekt aufgenommen werden soll. Zunächst importiert man diese Bibliothek in das Repository. Es bietet sich an, hierfür ein eigenes Verzeichnis im Repository anzulegen. Dieses sollte außerhalb der normalen Entwicklungsverzeichnisse liegen. Man legt dazu beispielweise das Verzeichnis vendor unterhalb der Repository-Wurzel an:
svn mkdir http://svn.myserver.de/repos/vendor -m "vendor branches"
Das Verzeichnis vendor dient als Speicherort für die fremde Software. Der Sourcecode des Vendors wird dort in ein Unterverzeichnis importiert:
svn import TextLib http://svn.myserver.de/repos/vendor/TextLib/current -m "Import von TextLib 1.0"
Das Unterverzeichnis current speichert nun die aktuelle Version der Bibliothek TextLib. Um diesen Versionsstand auch bei neuen Releases der TextLib zu behalten, sollte man noch ein Tag setzen:
svn copy http://svn.myserver.de/repos/vendor/TextLib/current http://svn.myserver.de/repos/vendor/TextLib/1.0 -m "Tag auf Version 1.0 der TextLib"
Den unterhalb des Verzeichnisses vendor abgelegten Sourcecode lässt man unangetastet. Das Verzeichnis dient nur als Speicher für die Releases des Fremdherstellers. Um die Bibliothek tatsächlich zu verwenden, wird sie in ein Unterverzeichnis des eigenen Projekts kopiert:
svn copy http://svn.myserver.de/repos/vendor/TextLib/current http://svn.myserver.de/repos/TextPrinter1/ trunk/TextLib -m "TextLib hinzugefuegt"
Von dieser neuen Stelle im Projekt aus wird die Bibliothek eingebunden und modifiziert, sofern dies notwendig ist. Solange der Hersteller der TextLib keine neue Version ausliefert, die im Projekt verwendet werden soll, kann normal weitergearbeitet werden.
Irgendwann liefert der Hersteller Version 2.0 der TextLib aus. Diese soll nun in das Projekt integriert werden. Dazu muss sie als erstes die alte Version im Repository im Verzeichnis /vendor/TextLib/current ersetzen. Diesmal kann kein Import durchgeführt werden, da im Repository ja bereits eine Version an der gleichen Stelle existiert. Man wählt daher eine andere Vorgehensweise. Man checkt eine lokale Arbeitskopie des Verzeichnisses /vendor/TextLib/current aus, sofern man keine besitzt. Dort kopiert man nun die neuen Dateien der TextLib 2.0 hinein. Dabei werden einige Dateien durch neuere Versionen ersetzt werden, wahrscheinlich sind Dateien hinzugekommen, vielleicht sind auch Dateien gelöscht worden. Diese Änderungen muss man nun ins Repository überführen. Neue Dateien werden mit dem Befehl add hinzugefügt, gelöschte Dateien mit delete entfernt, eventuell werden Dateien mit dem Befehl move umbenannt. Bei vielen Änderungen kann dieser Arbeitsschritt etwas mühsam und unübersichtlich sein. Das Ergebnis checkt man anschließend wieder ein. Auch für diese neue Version sollte man ein Tag anlegen:
svn copy http://svn.myserver.de/repos/vendor/TextLib/current http://svn.myserver.de/repos/vendor/TextLib/2.0 -m "Tag auf Version 2.0 der TextLib"
Jetzt müssen die Änderungen der neuen Version in das Projekt übernommen werden. Diese Zusammenführung nimmt man in einer Arbeitskopie des Projekts vor. Es sollen die Änderungen zwischen den Versionen 1.0 und der aktuellen Version von TextLib in die modifizierte Version von TextLib in der lokalen Arbeitskopie überführt werden. Dazu ruft man folgenden Befehl auf:
svn merge http://svn.myserver.de/repos/vendor/TextLib/1.0 http://svn.myserver.de/repos/vendor/TextLib/current TextLib
Subversion bestimmt nun die Änderungen zwischen der Version 1.0 und der aktuellen Version der TextLib und fügt diese Änderungen in die TextLib in der lokalen Arbeitskopie ein. Bei dieser Zusammenführung kann es natürlich zu Konflikten kommen. Diese müssen nun vom Entwickler aufgelöst werden. Anschließend kann er die neue, angepasste Version der fremden Bibliothek ins Repository einchecken.
Die erneute Übernahme der Fremdbibliothek in das Repository erweist sich als mühsamer Schritt, wenn sich an der Struktur des Sourcecodes viele Änderungen ergeben haben. Die neu hinzugefügten Dateien, die gelöschten Dateien und die umbenannten Dateien müssen zunächst identifiziert und anschließend mit den Befehlen add, delete und move passend bearbeitet werden. Das Gleiche gilt für neue, gelöschte oder verschobene Verzeichnisse.
Zur vereinfachten erneuten Übernahme von fremden Sourcecode in Subversion kann das Skript svn_load_dirs.pl verwendet werden. Es handelt sich um ein Perl-Skript, das man im Verzeichnis contrib/client-side des Subversion Sourcecodes findet. Dieses Skript kümmert sich um die notwendigen add, delete und move-Opertationen. Eine Beschreibung liegt dem Skript bei.
