2017-01-20 3 views
0

Ich habe einige Projekte und das Framework, das sie in einem SVN-Repository verwenden; Nennen wir dieses Repository A. Jetzt möchte ich das Framework mit einem anderen Team in einem anderen SVN-Repository teilen (nennen wir es B), aber ich möchte alle Änderungen an dem Framework, die an B gebunden sind, auch auf A verfügbar sein.* Teil von * zwei SVN-Repositories synchron halten

Natürlich kann ich ab und zu überprüfen, was auf Server B neu ist, updaten, auf eine Arbeitskopie von Server A kopieren und dort committen. Aber ich würde auch gerne alle Historien behalten (sollte kein Problem sein, da der Autor eines Commits anscheinend nur eine Namenszeichenfolge ist), und ich würde das lieber automatisch machen, wenn jemand auf Server B (im Framework-Verzeichnis) schreibt.

Hinweis: In der Zwischenzeit leben Server A und seine Projekte und seine Framework-Version ihr eigenes Leben. Zusammengefasst, es ist ein bisschen wie Zweige, aber auf verschiedenen Repositories, und A zu B sollte wie eine Zusammenführung sein, aber B zu A würde vorzugsweise die Geschichte der Änderungen auch behalten.

Ist es möglich zu tun? Wie kann ich das erreichen?

Antwort

1

Sie haben zwei Möglichkeiten:

  1. Sie den Inhalt von A nach B überhaupt nicht kopieren/synchronisieren. Verwenden Sie stattdessen svn:externals, um die entsprechenden Elemente aus A in Arbeitskopien zu ziehen, die aus B ausgecheckt wurden. Dadurch werden Sie keinen Code von A nach B duplizieren und jedes Mal, wenn Sie Ihr WC aus B auschecken oder aktualisieren die "neuesten" von A.
  2. Verwendung svnsync synchronisieren selektiv Teile des Repository A an Repository B. vom manual:

ab Subversion 1.5, svnsync hat auch die Möglichkeit, eine Untergruppe von spiegeln eher ein Repository als das Ganze. Der Prozess zum Einrichten und Pflegen einer solchen Spiegelung ist genau der gleiche wie beim Spiegeln eines gesamten Repositorys, außer dass Sie bei der Ausführung von svnsync init die URL eines Unterverzeichnisses in diesem Repository angeben, anstatt die Stamm-URL des Quell-Repositorys anzugeben. Bei der Synchronisation mit dieser Spiegelung werden jetzt nur die Bits kopiert, die sich in dem Unterverzeichnis des Quell-Repositorys geändert haben. Diese Unterstützung unterliegt jedoch einigen Einschränkungen. Erstens können Sie mehrere disjunkte Unterverzeichnisse des Quell-Repositorys nicht in einem einzigen Spiegel-Repository spiegeln. Sie müssen stattdessen ein gemeinsames Eltern-Verzeichnis spiegeln, das beiden gemeinsam ist. Zweitens ist die Filterlogik vollständig pfadbasiert. Wenn das Unterverzeichnis, das Sie spiegeln, zu einem bestimmten Zeitpunkt in der Vergangenheit umbenannt wurde, enthält Ihre Spiegelung nur die Revisionen seit dem Erscheinen des Verzeichnisses unter der von Ihnen angegebenen URL. Wenn das Quellenunterverzeichnis in Zukunft umbenannt wird, stoppen Ihre Synchronisierungsprozesse außerdem die Spiegelung von Daten an dem Punkt, an dem die von Ihnen angegebene Quell-URL nicht mehr gültig ist.

+0

Ich habe nicht bemerkt, dass ich externals definieren kann, um auf ein anderes Repository zu verweisen! Das ist großartig, aber ... wie würde ich mit dem Zugriff umgehen? Beide Repositories müssten die gleichen Accounts haben - oder zumindest sollte ich einen Account verschenken, den Mitglieder von Team B benutzen können, um auf den freigegebenen Code auf Server A zuzugreifen ... – Simone

+1

Ja, Benutzer benötigen Zugriff auf beide Repositories (Die Konten müssen nicht unbedingt die gleichen Namen oder Passwörter haben). Geben Sie kein "geteiltes" Konto für alle Benutzer an, die mit den externen Daten verwendet werden sollen. Wie Sie dies verwalten, hängt davon ab, wie Sie Ihre Authentifizierung und Autorisierung einrichten. – alroc

+0

Mit svnsync, stattdessen müsste ich nicht die Benutzer von B auf A authentifizieren lassen, habe ich Recht? – Simone

Verwandte Themen