So aktualisieren Sie Subversion external

Question

Wir haben mehrere Subversion-Repositories: einen für gemeinsamen Code und einen für jedes Top-Level-Projekt. Die Top-Level-Projekte haben eine svn: externe Verbindung zum Stamm des gemeinsamen Repositories.

Bevor wir ein Release eines Projekts erstellen, erstellen wir einen Zweig des Top-Level-Projekts und erstellen auch einen parallelen Zweig im gemeinsamen Repository.

Wie können wir automatisch sicherstellen, dass die Eigenschaft svn: external im verzweigten Projekt der obersten Ebene auf den parallelen Zweig im gemeinsamen Verzeichnis zeigt - derzeit wird es im gemeinsamen Repository auf "trunk" zeigen. Wir müssen dies im verzweigten Projekt derzeit manuell bearbeiten.

Dank

Answer 1

Wenn ich Sie verstehe, wollen Sie sicherstellen, dass foo und bar die gleiche Branche zu teilen lassen. foo ist Ihr Master-Projekt und hat eine svn:externals darauf irgendwo zeigt auf bar. Wenn Sie foo verzweigen, möchten Sie sicherstellen, dass bar denselben Zweig verwendet. Die einzige Möglichkeit, dies sicherzustellen, besteht darin, Ihr Repository mit den Verzeichnissen tags und branches im Stammverzeichnis Ihres Repositorys anstatt im Stammverzeichnis des Projekts zu erstellen (wie bei den meisten anderen Sites).

Dann können Sie relative externe Referenzen verwenden, um aus dem Verzeichnis foo zu verweisen, das die svn:external zurück zu bar enthält. Auch, wenn Sie foo markieren und eine Bar mit dem gleichen Tag, foo und bar wird ihre Beziehung pflegen:

$ svn propset svn:externals ../../bar common 

Wenn Ihre Zweige an der Wurzel Ihrer Repository waren, dann ist das common Verzeichnis wird auf dem gleichen Zweig werden zeigen für foo wie es ist auf bar. Das große Problem mit snv:externals ist, dass Sie, wenn Sie nicht vorsichtig sind, auf eine sich ständig ändernde Version des Verzeichnisses zeigen, mit dem Sie verlinken. Nehmen wir an, jemand hat folgendes getan:

$ svn propset svn:externals /projects/bar/trunk common 

in meinem foo Projekt. Ich mache eine Freigabe und kopiere foo auf ein Tag. Das Verzeichnis common, das ich markiert habe, wird jedoch geändert, wenn jemand bar/trunk aktualisiert. Dies macht es fast unmöglich, foo wieder aufzubauen.

Wenn ich svn:externals verwende, stelle ich immer sicher, dass ich entweder eine getaggte Version von bar oder eine bestimmte Revision verknüpfe, und wenn ich auf eine bestimmte Revision verlinke, picke ich auch meine URL zu dieser Revision jemand beschließt, das Verzeichnis zu löschen, das ich mit meiner svn:externals-Eigenschaft verknüpfe.

Es gibt nichts in Subversion, die automatisch Ihre svn:externals Eigenschaften aktualisieren, aber Sie können für alle SVN-Suche: unter Verwendung

$svn propget -v -R svn:externals . 

Ich habe festgestellt, dass svn:externals in der Regel endet als ein größeres Äußerlichkeiten auf einem Verzeichnisbaum Schmerz, als es wert ist.

Stattdessen speichern ich einfach das gebaute Objekt bar oder eine gezippte Kopie der Quelle in meinem Release-Repository, und als Teil meiner Build-Prozedur kopiere ich das Objekt oder gezippte Quelle aus meinem Release-Repository.

Ich benutze Maven-Site-Repositories wie Nexus oder Artifactory als Release-Repository, auch wenn ich kein Maven-Projekt mache oder sogar in einem Java-basierten Projekt arbeite. Das lokale Maven-Repository bietet alle Tools, die Sie zum Hoch- und Herunterladen Ihrer abhängigen Pakete benötigen, und Maven hat das Konzept Release Repository - wo der Code sich nie ändert - und ein Snapshot Repository, wo Sie planen, zu veröffentlichen der Code, aber es könnte sich ändern. Dies ist hilfreich, wenn Sie vermuten, dass sich bar aufgrund von benötigtem Material in foo ändern kann.