2010-12-01 10 views
3

Wir haben eine ziemlich große Bibliothek, die wir regelmäßig in unsere Codebasis importieren (und dann patchen) müssen.SVN: Hersteller Filialen + Patch + Geschichte?

Das SVN Buch scheint ein "Vendor Branch" Schema zu empfehlen, wo wir unsere gepatchte Version des "Vendor Drops" behalten. Dies würde funktionieren, außer dass der Anbieter auch SVN verwendet und uns Lesezugriff auf ihre Reops gibt.

Es wäre großartig, Zugriff auf den Verlauf der Herstellerdateien zu haben, wenn wir unsere Patches aktualisieren müssen.

Also meine Frage ist:

Gibt es eine Möglichkeit, einen gepatchte „Herstellerzweig“ zu haben, die irgendwie Zugriff auf die Geschichte auch Dateien für die Anbieter halten?

(Ich habe erwähnt svn gesehen. Externe Ordner, aber ich bin nicht sicher, ob ich wirklich die vollen Auswirkungen in Bezug auf die verstehen, eine Revision Pegging, noch, wie genau würden wir unsere eigene Patches dagegen halten)

Was ist der richtige Weg hier zu nehmen? (FWIW, die Lieferantenstände einmal im Monat. Wir beabsichtigen, Updates etwa einmal ziehen/zweimal im Jahr.)

Dank

+0

Es ist nicht die Antwort, die Sie erwartet haben, aber (obwohl ich Svn wirklich mag), wenn Sie erwarten, intensiv mit Filialen zu arbeiten, dann könnte SVN keine gute Entscheidung für Sie sein. Anstelle von SVN schlage ich vor, dass Sie Mercurial oder GIT betrachten. Mercurial ist einfacher, ich benutze es für meine privaten Projekte und GIT ist leistungsfähiger. – zerkms

+1

@zerkms Ja, SVN ist eine "Geschäftsanforderung", leider. Keine Wahl in der Sache. – nonot1

+0

@zerkms, Verzweigung funktioniert gut in Subversion.Sie müssen nur wissen, wie man die Werkzeuge einsetzt und welche Techniken und Methoden zur Versionskontrolle Sie beherrschen. – jgifford25

Antwort

2

Okay, hier ist der Haken, möchten Sie die Quelle des Anbieters zusammen mit der Geschichte, aber auch Wenden Sie Ihren Patch auf die Quelle des Anbieters an. Ihre Quelle mit Geschichte zu erhalten ist einfach. Ihre Quelle mit Geschichte zu versorgen und dann Ihre Patches anzuwenden und dies kontinuierlich zu tun, das ist hart.

Wenn Sie nun davon ausgehen, dass Sie das Quellenverzeichnis des Herstellers nicht in Ihre Quelle einfügen (dh Sie erstellen die beiden Projekte separat), haben Sie mehrere Optionen, wenn Sie die beiden Quellen in separaten Repositorys aufbewahren.

Wenn Sie die Lieferantenquelle zusammen mit dem Verlauf verwenden möchten, können Sie einen svnsync für das Lieferantenrepository einrichten und deren Änderungen in regelmäßigen Abständen abrufen. Svnsync ist eine wundervolle Möglichkeit, etwas als lokale Kopie mit einem kompletten Satz von Geschichte fern zu bekommen. Der einzige Nachteil von svnsync ist, dass das Repository schreibgeschützt wird. Sie können den Patch also nicht auf die Quelle anwenden.

Jetzt, da Sie dies nur ein- oder zweimal pro Jahr tun, können Sie eine neue Kopie ihres Repositorys mithilfe von svnsync erstellen. Brechen Sie die Synchronisierung und machen Sie Ihre Kopie des Repos des Herstellers beschreibbar und wenden Sie dann Ihre Patches an.

Die andere Möglichkeit wäre, dass der Hersteller einen Speicherauszug ihres Repo erstellt und an Sie sendet. Dann würden Sie diesen Speicherauszug in Ihr eigenes Repository laden und lesen/schreiben.

Bei jeder dieser Optionen müssen Sie Ihre Patches jedes Mal erneut auf Ihre Kopie des Repository des Anbieters anwenden, wenn Sie diesen Prozess durchlaufen. Zumindest tust du das nur ein- oder zweimal im Jahr.

Jetzt, wenn Sie ihre Quelle in Ihrer Quelle haben müssen, tun Sie immer noch das oben genannte, aber benutzen Sie das svn: external, wie Sie in Ihrer Frage notiert haben. Sie müssen dennoch alle Patches, die Sie an die Quelle des Anbieters vornehmen müssen, auf Ihre Kopie des Repository des Anbieters anwenden.

+0

Können Sie klarstellen, was Sie mit svn: externals meinen? Kann ich einen gepatchten Zweig in meinem eigenen Repo basierend auf svn: external pflegen? – nonot1

+1

Klärung der Verwendung von svn: externals: Sie würden die Quelle des Anbieters in einem eigenen Repository zusammen mit Ihren spezifischen Patches für die Quelle des Anbieters haben. Wenn Ihr Projekt (in seinem eigenen Repository) auch die Quelle des gepatchten Lieferanten zusammen mit seiner eigenen Quelle kompiliert, wäre die Verwendung von svn: externals die beste Lösung dafür. Dies liegt daran, dass Sie angegeben haben, dass Sie regelmäßig die neueren Versionen der Lieferantenquelle verwenden. Das würde es Ihnen ermöglichen, die Lieferantenquelle einfacher auszutauschen. – jgifford25

+1

@ nonot1: Ich würde die Lieferantenquelle nicht als Zweig behandeln, sondern als separates Projekt in einem eigenen Repository. Dies würde es erleichtern, die Aktualisierung der Lieferantenquelle zu automatisieren. Die Quelle des Anbieters in einem separaten Repository funktioniert jedoch wie ein Zweig, auf den Sie eigene Patches anwenden können. Von dort können Sie dann die svn: externals verwenden, um Ihre Projektquelle einzubinden (falls erforderlich). – jgifford25