Subversion - Zusammenführen von Repositories

Question

Als ich zuerst die SVN-Struktur für meine verschiedenen Projekte eingerichtet habe, habe ich beschlossen, jedes andere Projekt in einem separaten Repository zu platzieren.

Dies hat für eine Weile gut funktioniert, aber ich bin der Meinung, dass ich alle diese Repositories in einem übergreifenden "unternehmensweiten" Repository zusammenführen möchte, wenn Mitarbeiter den Quellcode auschecken kann einfach von oben auschecken und den ganzen Code aus den verschiedenen Projekten haben.

Ich fand die svn-merge-repos Befehl online, aber nicht viele Benutzer Feedback oder hilfreiche Tipps für die Verwendung. Ist dies der beste Weg, Repositories beizutreten, damit ich meine Verlaufsdaten nicht verliere, oder gibt es einen besseren Weg? Gibt es irgendwelche Fallstricke, auf die ich achten sollte?

Danke.

Answer 1

Bitte erzwingen Sie bitte nicht, dass Ihre Benutzer ein gesamtes Repository auschecken, um die Dinge zu erstellen. Dies erinnert an das alte quelloffene Modell und war damals nicht gut.

Mit einem Repository pro Projekt ist fein. Wenn Projekt1 Code aus Projekt2 benötigt, fügen Sie eine Eigenschaft "svn: externals" zum Stamm von project1 hinzu, die project2 an einen sinnvollen Ort im Verzeichnis von project1 bringt. Wenn Projekt2 den Code von project3 benötigt, kann er auch eine externe Eigenschaft haben und den Code darunter einfügen.

Es ist eigentlich am besten, wenn die externe Referenzen immer auf ein Tag oder eine bestimmte Revision verweist, aber ich werde Sie auf Stamm verweisen, wenn Sie das Problem "ein riesiger Projektbereich" vermeiden.

Wenn Sie mit externen arbeiten, kann jeder einfach das gewünschte Projekt auschecken und automatisch bekommen alle Abhängigkeiten und einfach wegbauen - ganz wie Sie wollen. Ihr gesamter Code ist in einem einzigen Arbeitsverzeichnis enthalten, das genau das enthält, was sie brauchen. Sie können mehrere Versionen mehrerer Projekte in separaten Arbeitsverzeichnissen auschecken, ohne Platz zu verschwenden und trotzdem den Überblick zu behalten, was zur Hölle passiert.

Es kann eine geringfügige Umgestaltung Ihres Arbeitsbereichs erforderlich sein, wenn Projekt1 erwartet, Projekt2 außerhalb des Projektordners statt innerhalb zu finden, aber das ist eine kleine Verbesserung im großen Schema der Dinge.

Wenn Sie Ihr Herz wirklich auf ein einziges Repository legen, ist das auch in Ordnung (das verwenden wir an meinem Arbeitsplatz, und zu Hause, um darüber nachzudenken), stellen Sie jedoch sicher, dass Sie eine Struktur für jedes Projekt haben hat seine eigenen Tags, Stamm & Filialen Ordner, und das Auschecken der Kofferraum von project1 ist alles, was Sie tun müssen, um den Code für Projekt1 zu erstellen.

Schließlich, wenn Sie wirklich ein funky Layout für Ihre Projekte benötigen, können Sie ein zusätzliches einzelnes Repository hinzufügen, das ist im Wesentlichen ein Meta-Repository. Dieses Repository enthält 1 Verzeichnis pro Top-Level-Projekt (mit Stamm-Tags & Verzweigungen), und verwenden Sie externe, verweisen Sie auf alle anderen Projekte und erstellen Sie den funky Workspace genau so, wie Sie es erwarten.

Auf diese Weise erhalten Sie durch Hinzufügen des zusätzlichen Repositorys alle Vorteile des Auscheckens und Erstellens in einem Schritt und haben zumindest die Chance, Situationen zu meistern, in denen für Projekt1 erforderliche Änderungen aufgrund von Code, der mit project2 geteilt wird, brechen Sie müssen plötzlich eine Notfall-Lösung für Projekt 3 bekommen.

Answer 2

Sie können svn-merge-repos.pl verwenden, oder Sie können mehrere Repository-Sicherungen mit SvnDumpTool zusammenführen und dann den resultierenden Speicherauszug mit svnadmin load --ignore-uuid laden.

Beachten Sie, dass alle Revisionen neu nummeriert werden.

Überprüfen Sie den Zusammenführungsabschnitt von SvnDumpTool readme.

Answer 3

Wenn Sie nur die Repositories vereinheitlicht aussehen möchten, können Sie die svn: externals -Eigenschaft verwenden, so dass ein einziger Checkout Code aus allen vorhandenen Repos einlesen wird.

Answer 4

Tun Sie das nicht. Wie @KeithB sagt, sollte es sinnvoll sein, sie mit svn: externals zu referenzieren.

Es ist besser, jedes Projekt auf seinem eigenen Repository zu verwalten, so dass Sie alte Projekte leicht archivieren können, und auch für eine bessere Integrität.

Zum Beispiel behält die Apache-Stiftung a single repository für alle seine Projekte bei (ich weiß nicht, ob es von anderen Repos repliziert wird oder es ist das Live). Gerade jetzt, es ist Geschichte Gewichte 700k + Revisionen. Ich möchte nicht sehen, dass dieses Monster beschädigt wird.

Answer 5

Vor kurzem hatte ich etwas Ähnliches und was zu tun ich tat, war im Wesentlichen:

* svnadmin create X:\Repositories\RepositoryC 
* svn mkdir http://localhost:8080/svn/RepositoryC/branches --message "Added the branches folder." 
* svn mkdir http://localhost:8080/svn/RepositoryC/tags --message "Added the tags folder." 
* svn mkdir http://localhost:8080/svn/RepositoryC/trunk --message "Added the trunk folder." 
* svn mkdir http://localhost:8080/svn/RepositoryC/trunk/A --message "Added the trunk\A folder." 
* svn mkdir http://localhost:8080/svn/RepositoryC/trunk/B --message "Added the trunk\B folder." 
* svn checkout http://localhost:8080/svn/RepositoryC RepositoryC 
* svnadmin dump X:\Repositories\RepositoryA > RepositoryA.dmp 
* svnadmin dump X:\Repositories\RepositoryB > RepositoryB.dmp 
* svnadmin load X:\Repositories\RepositoryC --parent-dir trunk\A < RepositoryA.dmp 
* svnadmin load X:\Repositories\RepositoryC --parent-dir trunk\B < RepositoryB.dmp 
* svn checkout http://localhost:8080/svn/RepositoryC RepositoryC 

NB: Der obige Code wird davon ausgegangen, dass auf dem Rechner, Ihre Subversion-Repositorys hostet, existieren die Repositories auf X: \ Repositories und die URL zum Subversion-Server ist http://localhost:8080 und die eine befindet sich im Arbeitsordner.

An diesem Punkt werden Sie mit RepositoryC enden, das RepositoryA und RepositoryB darin unter trunk \ A bzw. trunk \ B hat, und am wichtigsten ist, dass Ihre Änderungshistorie sowohl für RepositoryA als auch für RepositoryB gepflegt wurde. Ihr Arbeitsordner enthält auch einen Ordner mit dem Namen RepositoryC, der ein Auschecken des RepositoryC enthält.

Sie können jetzt Dinge in RepositoryC verschieben, um die Projektstrukturen der beiden Repositories RepositoryA und RepositoryB zu vereinheitlichen.