Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.

Lieferanten-Zweige
Zurück  Kapitel 4. Verzweigen und Zusammenführen  Weiter

Lieferanten-Zweige

Besonders in der Software-Entwicklung haben Ihre versionsverwalteten Daten oft einen engen Bezug zu Daten aus anderen Quellen oder sind vielleicht sogar davon abhängig. Im allgemeinen wird es ihr Projekt erfordern, dass Sie hinsichtlich dieser externen Datenquelle so aktuell wie möglich bleiben, ohne dabei die Stabilität des Projektes zu opfern. Dieses Szenario taucht immer dort auf, wo die von einer Gruppe erzeugten Informationen direkte Auswirkungen auf diejenigen Informationen haben, die von einer anderen Gruppe erstellt werden.

Software-Entwickler könnten beispielsweise an einer Anwendung arbeiten, die die Bibliothek eines Drittanbieters benötigt. Subversion hat eine solche Abhängigkeit von der Bibliothek Apache Portable Runtime (APR) (siehe „Die Bibliothek Apache Portable Runtime“). Der Quelltext von Subversion hängt zur Gewährleistung der Portabilität von der APR-Bibliothek ab. In der frühen Phase der Entwicklung von Subversion hing das Projekt ziemlich nah am wechselnden API der APR, indem es immer die neueste Version des Quelltextes verwendete. Nun, da sowohl APR und Subversion gereift sind, versucht sich Subversion nur zu wohldefinierten Zeitpunkten mit dem APR-API zu synchronisieren, nämlich wenn dieses ausreichend getestet und stabil ist.

Falls nun Ihr Projekt von den Informationen anderer abhängt, können Sie diese Informationen auf mehrere Arten mit Ihren synchronisieren. Am umständlichsten ist es, wenn Sie mündliche oder schriftliche Anweisungen an alle Projektmitarbeiter ausgeben, dass sie sicherzustellen haben, stets über die für Ihr Projekt benötigten Versionen der Drittanbieter zu verfügen. Falls die Daten des Drittanbieters sich in einem Subversion-Projektarchiv befinden, können Sie auch mithilfe der Subversion-Externals-Definition bestimmte Versionen dieser Daten mit Ihrer eigenen Arbeitskopie verbinden (siehe „Externals-Definitionen“).

Allerdings möchten Sie von Zeit zu Zeit spezielle Anpassungen des Drittanbieter-Codes in Ihrem eigenen Versions-Kontroll-System verwalten. Um auf unser Beispiel aus der Software-Entwicklung zurückzukommen, müssen Entwickler manchmal die Bibliothek der Drittanbieter für ihre Zwecke verändern. Diese Änderungen können neue Funktionalitäten oder Fehlerbehebungen umfassen und werden nur solange intern verwaltet, bis sie eines Tages Teil einer offiziellen Auslieferung der Bibliothek werden. Es kann aber auch sein, dass diese Änderungen niemals an die Entwickler der Bibliothek zurückgegeben werden, sondern lediglich als spezielle Anpassungen für die Bedürfnisse der Software-Entwickler bestehen bleiben.

Nun sind Sie in einer interessanten Situation: Ihr Projekt könnte seine Änderungen an den Daten von Drittanbietern auf getrennte Art und Weise verwalten, etwa in Form von Patch-Dateien oder als vollständig alternative Versionen. Jedoch wird so etwas schnell zu einem Albtraum, wenn es um die Pflege geht, und es wird ein Mechanismus benötigt, um die Änderungen auf den Code des Drittanbieters anzuwenden und diese Anpassung bei jeder Folgelieferung zu wiederholen.

Die Lösung dieses Problems besteht in der Verwendung von Lieferanten-Zweigen. Ein Lieferanten-Zweig ist ein Verzeichnisbaum in Ihrem eigenen Versions-Kontroll-System, der Informationen enthält, die von einem Drittanbieter – oder Lieferanten – bereitgestellt wird. Jede Version der Lieferantendaten, die Sie in Ihr Projekt aufnehmen wollen, wird Zulieferung genannt.

Lieferanten-Zweige bieten zwei Vorteile. Erstens, wird durch das Vorhalten der aktuellen Zulieferung in Ihrem eigenen Versions-Kontroll-System sichergestellt, dass für Ihre Projektmitarbeiter stets die richtige Version der Lieferantendaten verfügbar ist. Sie erhalten die richtige Version automatisch beim Aktualisieren ihrer Arbeitskopien. Zweitens, da die Daten in Ihrem eigenen Subversion-Projektarchiv liegen, können Sie dort auch Ihre Anpassungen speichern – es besteht somit keine Notwendigkeit mehr, Ihre Änderungen automatisch (oder schlimmer noch, manuell) in die Zulieferungen einzuarbeiten.

Unglücklicherweise existiert kein Königsweg, um Lieferanten-Zweige in Subversion zu verwalten. Die Flexibilität des Systems bietet mehrere verschiedene Ansätze, die alle ihre Vor- und Nachteile haben, und von denen keiner als „Patentrezept“ für das Problem bezeichnet werden kann. Wir werden einige dieser Ansätze in den nächsten Abschnitten auf einer hohen Ebene behandeln und dabei als Beispiel ein Software-Projekt verwenden, das von einer Bibliothek eines Drittanbieters abhängt.

Allgemeines Vorgehen für die Verwaltung von Lieferanten-Zweigen

Die Fortführung von Anpassungen an einer Bibliothek von Drittanbietern erfordert drei Datenquellen: die Version der Bibliothek des Drittanbieters, auf die die Anpassungen zuletzt aufgesetzt haben, die angepasste Version (d.h., der eigentliche Lieferanten-Zweig) der Bibliothek, die von Ihrem Projekt verwendet wird und irgendeine neue Version der Bibliothek, auf die Sie zu aktualisieren hoffen. Die Verwaltung des Lieferanten-Zweigs (der nach unserer Definition innerhalb Ihres Quelltext-Projektarchivs leben sollte) besteht dann im Wesentlichen aus Merge-Operationen (im allgemeinen Sinn). Doch verfolgen unterschiedliche Teams auch unterschiedliche Ansätze gegenüber den anderen Datenquellen – den unveränderten Versionen des Quelltextes der Drittanbieter-Bibliothek. Aus diesem Grund gibt es wahrscheinlich verschiedene besondere Wege, die benötigten Merges auszuführen.

Strenggenommen können diese Merges im allgemeinen Sinn auf verschiedene Weisen durchgeführt werden. Aus Gründen der Einfachheit und mit dem Ziel, wenigstens etwas Konkretes in diesem Abschnitt des Buches zu liefern, gehen wir davon aus, dass es lediglich einen einzigen Lieferanten-Zweig gibt, der ständig Upgrades auf die neueste herausgegebene Version der Drittanbieter-Bibliothek erhält, indem er Aktualisierungen bekommt, die die Unterschiede zwischen der gegenwärtigen und der neuen unveränderten Version der Bibliothek beschreiben.

[Anmerkung] Anmerkung

Ein weiterer Ansatz ist es, neue Lieferanten-Zweige für jede nachfolgende unveränderte Version der Bibliothek anzulegen und die Unterschiede zwischen der aktuellen unveränderten und ihrer angepassten Version (vom aktuellen Lieferanten-Zweig) auf den neuen Zweig anzuwenden. An diesem Ansatz gibt es nichts auszusetzen, jedoch sind wir der Meinung, dass wir nicht jede berechtigte Möglichkeit an dieser Stelle dokumentieren müssen.

Die folgenden Abschnitte untersuchen, wie Lieferanten-Zweige in ein paar unterschiedlichen Szenarios erzeugt und verwaltet werden. In den folgenden Beispielen nehmen wir an, dass die Bibliothek des Drittanbieters libcomplex heißt, und wir einen Lieferanten-Zweig basierend auf libcomplex 1.0.0 anlegen, der in unserem Projektarchiv unter ^/vendor/libcomplex-custom liegt. Wir werden uns dann ansehen, wie wir einen Upgrade auf libcomplex 1.0.1 machen können und gleichzeitig unsere Anpassungen an die Bibliothek bewahren können.

Lieferanten-Zweige aus fremden Projektarchiven

Sehen wir uns zunächst einen Ansatz zur Verwaltung von Lieferanten-Zweigen an, der möglich ist, falls die originale Drittanbieter-Bibliothek selbst über Subversion erreichbar ist. Für das Beispiel nehmen wir an, dass die besprochene Bibliothek libcomplex in einem öffentlich zugänglichen Subversion-Projektarchiv entwickelt wird und deren Entwickler vernünftige Freigabeverfahren verwenden, zu denen die Erzeugung von Tags für jede stabile freigegebene Version zählt.

Seit Subversion 1.5 kann svn merge sogenannte Merges aus fremden Projektarchiven ausführen, wobei die Quellen des Merges in einem anderen Projektarchiv liegen, als das Projektarchiv, aus dem die Arbeitskopie des Merge-Ziels ausgecheckt wurde. Und in Subversion 1.8 wurde das Verhalten von svn copy dergestalt geändert, dass beim Kopieren aus einem fremden Projektarchiv in eine bestehende Arbeitskopie der so entstandene Baum in diese Arbeitskopie aufgenommen wird und zum Hinzufügen vorgemerkt wird. Mit genau dieser Funktionalität der Kopie aus fremden Projektarchiven werden wir unseren Lieferanten-Zweig aufsetzen.

Lassen Sie uns also unseren Lieferanten-Zweig erstellen. Wir beginnen damit, ein Verzeichnis als Platzhalter für alle derartigen Lieferanten-Zweige in unserem Projektarchiv anzulegen und dann eine Arbeitskopie daraus auszuchecken.

$ svn mkdir http://svn.example.com/projects/vendor \
            -m "Einen Container für Lieferanten-Zweige erstellen."
Revision 1160 übertragen.
$ svn checkout http://svn.example.com/projects/vendor \
               /path/to/vendor
Ausgecheckt, Revision 1160.
$

Nun nutzen wir Subversions Unterstützung für Kopien aus fremden Projektarchiven, um eine exakte Kopie von libcomplex 1.0.0 aus dem Projektarchiv des Drittanbieters zu bekommen – inklusive aller Subversion-Eigenschaften an den Dateien und Verzeichnissen.

$ cd /path/to/vendor
$ svn copy http://svn.othervendor.com/repos/libcomplex/tags/1.0.0 \
           libcomplex-custom
-- Kopieren aus fremdem Projektarchiv bei URL »http://svn.othervendor.com/rep\
os/libcomplex/tags/1.0.0«:
A    libcomplex-custom
A    libcomplex-custom/README
A    libcomplex-custom/LICENSE
…
A    libcomplex-custom/src/code.c
A    libcomplex-custom/tests
A    libcomplex-custom/tests/TODO
$ svn commit -m "Initialisierung des Lieferanten-Zweigs libcomplex aus libcomplex 1.0.0."
Füge hinzu         libcomplex-custom
Füge hinzu         libcomplex-custom/README
Füge hinzu         libcomplex-custom/LICENSE
…
Füge hinzu         libcomplex-custom/src
Füge hinzu         libcomplex-custom/src/code.h
Füge hinzu         libcomplex-custom/src/code.c
Übertrage Daten .......................................
Revision 1161 übertragen.
$
[Anmerkung] Anmerkung

Sollten Sie eine ältere Version von Subversion verwenden, ist die Vorgehensweise, die der neuen Unterstützung von Kopien aus fremden Projektarchiven durch svn copy am nächsten kommt, eine Arbeitskopie des Lieferanten-Tags zu importieren (mit svn import), und dabei die Optionen --no-auto-props und --no-ignore zu verwenden, so dass der komplette Baum und alle versionierten Eigenschaften akkurat in Ihrem Projektarchiv repliziert werden.

Da wir nun einen Lieferanten-Zweig basierend auf libcomplex 1.0.0 haben, können wir mit den für unsere Zwecke notwendigen Anpassungen an libcomplex beginnen und sie direkt in den erstellten Lieferanten-Zweig übertragen. Selbstverständlich können wir anfangen, libcomplex in unseren eigenen Anwendungen zu verwenden.

Nach einer Weile wird libcomplex 1.0.1 freigegeben. Nachdem wir uns die Änderungen angesehen haben, entscheiden wir uns, unseren Lieferanten-Zweig auf den Stand der neuen Version zu bringen. Hierbei ist Subversions Merge-Operation aus fremden Projektarchiven von Nutzen. Auf unserem Lieferanten-Zweig befindet sich die originale libcomplex 1.0.0 plus unserer Anpassungen daran. Wir müssen nun die Menge der Änderungen, die der Drittanbieter zwischen 1.0.0 und 1.0.1 gemacht hat, auf unseren Lieferanten-Zweig bringen, idealerweise, ohne dabei unsere Anpassungen zu überschreiben. Genau hierfür eignet sich die 2-URL-Form des Befehls svn merge.

$ cd /path/to/vendor
$ svn merge http://svn.othervendor.com/repos/libcomplex/tags/1.0.0 \
            http://svn.othervendor.com/repos/libcomplex/tags/1.0.1 \
            libcomplex-custom
-- Zusammenführen der Unterschiede zwischen fremden Projektarchiv-URLs in ».«:
U    libcomplex-custom/src/code.h
C    libcomplex-custom/src/code.c
U    libcomplex-custom/README
Konfliktübersicht:
  Textkonflikte: 1
Konflikt in Datei »libcomplex-custom/src/code.c« entdeckt.
Auswahl: (p) später auflösen, (df) Änderungen anzeigen,
         (e) Dateibearbeiten, (m) Zusammenführung,
         (mc) eigene Seite des Konflikts,
         (tc) fremde Seite des Konflikts, (s) alle Optionen anzeigen:

Wie Sie sehen können, hat svn merge die Änderungen, die notwendig sind, libcomplex 1.0.0 wie libcomplex 1.0.1 aussehen zu lassen, mit unserer Arbeitskopie zusammengeführt. In unserem Beispiel ist sogar ein Konflikt erkannt und markiert worden. Es schaut aus, als habe der Drittanbieter einen Bereich einer Datei geändert, den wir auch angepasst haben. Subversion entdeckt den Konflikt zuverlässig und bietet uns die Möglichkeit, ihn aufzulösen, so dass unsere Anpassungen auch mit der jetzigen libcomplex 1.0.1 immer noch sinnvoll sind. (Siehe „Lösen Sie etwaige Konflikte auf“ für Weiteres zum Auflösen derartiger Konflikte.)

Sobald wir die Konflikte aufgelöst sowie notwendige Tests und Überprüfungen gemacht haben, können wir die Änderungen in unseren Lieferanten-Zweig übertragen.

$ svn status libcomplex-custom
M       libcomplex-custom/src/code.h
M       libcomplex-custom/src/code.c
M       libcomplex-custom/README
$ svn commit -m "Lieferanten-Zweig au Stand libcomplex 1.0.1 bringen." \
             libcomplex-custom
Sende              libcomplex-custom/README
Sende              libcomplex-custom/src/code.h
Sende              libcomplex-custom/src/code.c
Übertrage Daten ...
Revision 1282 übertragen.
$

Das ist kurz und bündig, wie Lieferanten-Zweige verwaltet werden, falls die Original-Quellen für Subversion erreichbar sind. Es gibt jedoch einige erwähnenswerte Schwächen. Zunächst werden Merges aus fremden Projektarchiven nicht automatisch von Subversion verfolgt wie Merges innerhalb des eigenen Projektarchivs. Das bedeutet, der Anwender trägt die Last und muss wissen, welche Merges auf dem Lieferanten-Zweig stattgefunden haben und wie der nächste Merge aufzusetzen ist, wenn der Zweig aktualisiert werden soll. Ebenso, was für die gesamte Unterstützung von Merges durch Subversion gilt, können Umbenennungen der Merge-Quellen zu nicht geringen Komplikationen und Frustrationen führen. Unglücklicherweise sehen wir uns momentan außerstande, eine besonders zuverlässige Empfehlung zur Linderung dieses Schmerzes zu geben.

Lieferanten-Zweige aus gespiegelten Quellen

Im vorhergehenden Abschnitt („Lieferanten-Zweige aus fremden Projektarchiven“) haben wir uns angesehen, wie ein Lieferanten-Zweig angelegt und verwaltet wird, wenn die Zulieferungen über Subversion zu erreichen sind, was der Idealfall bei Lieferanten-Zweigen ist. Subversion kann sehr gut mit Merges von Dingen umgehen, die von Subversion verwaltet wurden. Unglücklicherweise trifft es nicht immer zu, dass Bibliotheken von Drittanbietern öffentlich über Subversion zugreifbar sind. Oftmals hängt ein Projekt von einer Bibliothek ab, die über Wege außerhalb von Subversion ausgeliefert wird, wie etwa Quelltext-Tarballs. Unter derartigen Umständen empfehlen wir dringend, alles zu tun, um diese Informationen außerhalb von Subversion möglichst sauber in Subversion einzupflegen. Lassen Sie uns nun einen Ansatz für Lieferanten-Zweige untersuchen, bei dem die verschiedenen freigegebenen Versionen der Drittanbieter-Bibliothek innerhalb unseres eigenen Projektarchivs gespiegelt werden.

Das erstmalige Aufsetzen des Lieferanten-Zweiges ist wirklich recht einfach. Für unser Beispiel nehmen wir an, dass libcomplex 1.0.0 über den verbreiteten Tarball-Mechanismus verteilt wird. Um unseren Lieferanten-Zweig zu erstellen, holen wir zunächst den Inhalt des libcomplex 1.0.0 Tarballs als nur-lesbaren (durch Konvention) Lieferanten-Tag in unser Projektarchiv.

$ tar xvfz libcomplex-1.0.0.tar.gz
libcomplex-1.0.0/
libcomplex-1.0.0/README
libcomplex-1.0.0/LICENSE
…
libcomplex-1.0.0/src/code.c
libcomplex-1.0.0/tests
libcomplex-1.0.0/tests/TODO
$ svn import libcomplex-1.0.0 \
             http://svn.example.com/projects/vendor/libcomplex-1.0.0 \
             --no-ignore --no-auto-props \
             -m "libcomplex 1.0.0 Quellen importieren."
Füge hinzu         libcomplex-custom
Füge hinzu         libcomplex-custom/README
Füge hinzu         libcomplex-custom/LICENSE
…
Füge hinzu         libcomplex-custom/src
Füge hinzu         libcomplex-custom/src/code.h
Füge hinzu         libcomplex-custom/src/code.c
Übertrage Daten .......................................
Revision 1160 übertragen.
$

Beachten Sie, dass wir in unserem Beispiel während des Imports die Option --no-ignore verwendeten, damit Subversion zuverlässig jede Datei der Zulieferung aufnimmt und keine ausläßt. Wir geben auch die Option --no-auto-props an, damit unser Client keine nicht in der Zulieferung enthaltene Eigenschafts-Informationen erzeugt.[46].

Nun, da sich die erste Zulieferung des Drittanbieters in unserem Projektarchiv befindet, können wir daraus unseren Lieferanten-Zweig anlegen, genauso, wie jeden anderen Zweig – mit svn copy.

$ svn copy http://svn.example.com/projects/vendor/libcomplex-1.0.0 \
           http://svn.example.com/projects/vendor/libcomplex-custom \
           -m "Initialize libcomplex vendor branch from libcomplex 1.0.0."
Revision 1161 übertragen.
$

Okay. An dieser Stelle haben wir einen Lieferanten-Zweig basierend auf libcomplex 1.0.0. Wir sind bereit, die für unsere Zwecke notwendigen Anpassungen an libcomplex vorzunehmen – indem wir sie direkt in den Lieferanten-Zweig übertragen – und unsere angepasste libcomplex in eigenen Applikationen zu verwenden.

Nach einer Weile wird libcomplex 1.0.1 freigegeben. Nachdem wir uns die Änderungen angesehen haben, entscheiden wir uns, unseren Lieferanten-Zweig auf den Stand der neuen Version zu bringen. Um diese Aktualisierung auf unserem Zweig vornehmen zu können, müssen wir im Prinzip dieselben Änderungsmengen auf unseren Lieferanten-Zweig anwenden, die der Lieferant zwischen 1.0.0 und 1.0.1 erstellt hat, ohne dabei unsere Anpassungen zu überschreiben. Die sicherte Weise, auf der das geschehen kann, ist es, zunächst libcomplex 1.0.1 in unser Projektarchiv zu holen als Delta zum Quelltext von 1.0.0 in unserem Projektarchiv. Anschließend verwenden wir die 2-URL-Form des Befehls svn merge zum Replizieren derselben Änderungen auf den Lieferanten-Zweig.

Es stellt sich heraus, dass es mehrere unterschiedliche Ansätze gibt, die wir verfolgen können, um libcomplex 1.0.1 auf die richtige Weise in unser Projektarchiv zu bekommen. [47] Der Ansatz, den wir hier beschreiben, ist relativ rudimentär, jedoch ist er unserer Beschreibung dienlich.

Erinnern Sie sich, dass wir möchten, dass die Spiegelung der Zulieferung von libcomplex 1.0.1 einen gemeinsamen Stammbaum mit unserer Zulieferung von 1.0.0 hat, was später zu den besten Ergebnissen führen wird, wenn wir die Änderungen zwischen diesen Zulieferungen in unseren Lieferanten-Zweig einbringen möchten. Wir beginnen also damit, einen Zweig für libcomplex-1.0.1 als Kopie unseres vorher erstellten libcomplex-1.0.0 „Lieferanten-Tags“ – eine Kopie, die schließlich eine Replik von libcomplex 1.0.1 wird.

$ svn copy http://svn.example.com/projects/vendor/libcomplex-1.0.0 \
           http://svn.example.com/projects/vendor/libcomplex-1.0.1 \
           -m "Einrichten eines Baugeländes für libcomplex 1.0.1."
Revision 1282 übertragen.
$

Nun müssen wir eine Arbeitskopie unseres libcomplex-1.0.1 Zweiges erstellen and ihn dann so herrichten, dass er eigentlich wie like libcomplex 1.0.1 aussieht. Um das zu erreichen, nutzen wir die Tatsache aus, das svn checkout ein bereits bestehendes Verzeichnis überlagern kann; wenn die Option --force angegeben wird, geschieht das auf eine Art und Weise, dass die Unterschiede zwischen dem ausgecheckten Baum und dem durch den Checkout überlagerten Zielbaum als lokale Änderungen in der Arbeitskopie verbleiben.

$ tar xvfz libcomplex-1.0.1.tar.gz
libcomplex-1.0.1/
libcomplex-1.0.1/README
libcomplex-1.0.1/LICENSE
…
libcomplex-1.0.1/src/code.c
libcomplex-1.0.1/tests
libcomplex-1.0.1/tests/TODO
$ svn checkout http://svn.example.com/projects/vendor/libcomplex-1.0.1 \
               libcomplex-1.0.1 \
               --force
E    libcomplex-1.0.1/README
E    libcomplex-1.0.1/LICENSE
E    libcomplex-1.0.1/INSTALL
…
E    libcomplex-1.0.1/src/code.c
E    libcomplex-1.0.1/tests
E    libcomplex-1.0.1/tests/TODO
Ausgecheckt, Revision 1282.
$ svn status libcomplex-1.0.1
M       libcomplex-1.0.1/src/code.h
M       libcomplex-1.0.1/src/code.c
M       libcomplex-1.0.1/README
$

Wie Sie sehen können, bleibt nach dem Auschecken von der eigentlichen libcomplex 1.0.0 über den ausgepackten libcomplex 1.0.1 eine Arbeitskopie mit lokalen Änderungen zurück – diejenigen Änderungen, die benötigt werden, um unsere bisherige freigegebene Zulieferung in unsere neue zu verwandeln.

Das ist zugegebenermaßen ein ziemlich einfaches Beispiel. Die für die Aktualisierung notwendigen Änderungen waren lediglich inhaltliche Änderungen an bestehenden Dateien. In der Realität könnten neue Versionen der Bibliotheken von Drittanbietern auch sowohl Dateien als auch Verzeichnisse hinzufügen oder entfernen, Dateien oder Verzeichnisse umbenennen, usw. In solchen Situationen kann es eine viel größere Herausforderung sein, das neue Lieferanten-Tag in einen Zustand zu überführen, in dem es exakt die Zulieferung wiedergibt, die es verspricht. Wir überlassen die Details derartiger Transformationen dem Leser als Übung.[48]

Wie auch immer wir es schaffen, sobald unsere neue auf dem Lieferanten-Tag basierende Arbeitskopie mit dem Original-Quellpaket abgeglichen ist, können wir diese Änderungen in unser Projektarchiv übertragen.

$ svn commit -m "Aktualisierung Lieferanten-Zweig auf libcomplex 1.0.1." \
             libcomplex-1.0.1
Sende              libcomplex-1.0.1/README
Sende              libcomplex-1.0.1/src/code.h
Sende              libcomplex-1.0.1/src/code.c
Übertrage Daten ...
Revision 1283 übertragen.
$

Wir sind schließlich soweit, dass wir unseren Lieferanten-Zweig aktualisieren können. Wenn Sie sich entsinnen, besteht unser Ziel darin, die vom Lieferanten zwischen den Versionen 1.0.0 und 1.0.1 ihrer Bibliothek gemachten Änderungen in unseren Lieferanten-Zweig zu bekommen. our vendor branch. An diesem Punkt betritt eine svn merge-Operation mit 2 URLs die Bühne, die auf eine Arbeitskopie unseres Lieferanten-Zweig angewendet wird.

$ svn checkout http://svn.example.com/projects/vendor/libcomplex-custom \
               libcomplex-custom
E    libcomplex-custom/README
E    libcomplex-custom/LICENSE
E    libcomplex-custom/INSTALL
…
E    libcomplex-custom/src/code.c
E    libcomplex-custom/tests
E    libcomplex-custom/tests/TODO
Ausgecheckt, Revision 1283.
$ cd libcomplex-custom
$ svn merge ^/vendor/libcomplex-1.0.0 \
            ^/vendor/libcomplex-1.0.1
-- Zusammenführen der Unterschiede zwischen Projektarchiv-URLs in ».«:
U    src/code.h
C    src/code.c
U    README
Konfliktübersicht:
  Textkonflikte: 1
Konflikt in Datei »src/code.c« entdeckt.
Auswahl: (p) später auflösen, (df) Änderungen anzeigen,
         (e) Dateibearbeiten, (m) Zusammenführung,
         (mc) eigene Seite des Konflikts,
         (tc) fremde Seite des Konflikts, (s) alle Optionen anzeigen:

Wie Sie sehen können, hat svn merge die erforderlichen Änderungen in unsere Arbeitskopie gebracht und einen Konflikt markiert, bei dem der Lieferant den gleichen Bereich einer der Dateien geändert hat wie wir während unserer Anpassungen. Subversion entdeckt diesen Konflikt und bietet uns die Gelegenheit zur Auflösung (mittels der in „Lösen Sie etwaige Konflikte auf“ beschriebenen Methoden), so dass unsere Anpassungen an, mittlerweile, libcomplex 1.0.1 weiterhin einen Sinn ergeben. Sobald wir die Konflikte aufgelöst sowie notwendige Tests und Überprüfungen gemacht haben, können wir die Änderungen in unseren Lieferanten-Zweig übertragen.

$ svn status
M       src/code.h
M       src/code.c
M       README
$ svn commit -m "Aktualisierung des Lieferanten-Zweigs auf libcomplex 1.0.1."
Sende              README
Sende              src/code.h
Sende              src/code.c
Übertrage Daten ..."
Revision 1294 übertragen.
$

Die Aktualisierung unseres Lieferanten-Zweiges ist vollbracht. Wenn wir beim nächsten Mal diesen Zweig aktualisieren müssen verfolgen wir die selbe Vorgehensweise, die wir bei der jetzigen Aktualisierung eingeschlagen sind.


[46] Technisch gesehen, könnten wir die Funktionalität der auto-props gewähren lassen, jedoch ist der Schlüssel des guten Gelingens, dass jede Zulieferung bezüglich auto-prop gleich behandelt wird.

[47] Die nochmalige Verwendung der Operation svn import Operation wäre ein falscher Ansatz, da die Zweige für libcomplex 1.0.0 und 1.0.1 keinen gemeinsamen Stammbaum hätten.

[48] Trotzdem ein Hinweis: svn add --force /path/to/working-copy --no-ignore --no-auto-props ist außerordentlich praktisch, um in dieser Situation alle neuen Objekte einer Zulieferung unter Versions-Kontrolle zu stellen.

Zurück  Nach oben  Weiter
Verbreitete Verzweigungsmuster  Zum Anfang  Verzweigen oder nicht verzweigen?