Subversion - Freigeben gemeinsamer Ordner ohne externe Elemente

Question

Meine SW-Gruppe versucht, unser Quellcodeverwaltungssystem von Visual Source Safe, das nicht mehr von Microsoft unterstützt wird, zu Subversion zu aktualisieren (weil unsere Schwestersite es bereits verwendet). Wir haben viel geteilten Code, der in VSS direkt mit internen Links gemacht werden kann. Diese müssen in freigegebene Ordner für mehrere zu verwendende Projekte verschoben werden. Obwohl externe Quellen verwendet werden können, um diese einzubringen, sind sie etwas riskant und nicht natürlich in die SVN-Architektur integriert (obwohl wir sie immer noch für Code von Drittanbietern und andere Dinge verwenden, die sich nicht ändern). Wie auch immer, wir haben eine Lösung gefunden, die ich nirgendwo anders gesehen habe, aber wir denken alle macht Sinn, also wollte ich sehen, was andere denken und ob es Fallstricke gibt (habe es noch nicht wirklich versucht).

So rufe ich diese "Shared Internal" Ordner, um mit externen zu kontrastieren. Angenommen, ich habe in meinem Repository-Stammverzeichnis ein Verzeichnis namens Common_Code, das generische Bibliotheksdateien für eine bestimmte Sprache enthält (in diesem Fall C++). Jetzt erstelle ich MyProject mit trunk/branches/tags und möchte den freigegebenen Ordner in ein Unterverzeichnis meines Projekts stellen. Also erstelle ich einen normalen Subversion-Zweig, der von Common_Code zu MyProject/trunk/Common_Code verzweigt. So arbeiten verschiedene Teammitglieder an MyProject, indem sie den Stamm abzweigen. Bobs Zweig könnte so aussehen: MyProject/branches/Bob_Working und der Unterordner würden zu MyProject/branches/Bob_Working/Common_Code verzweigen. Dies ist effektiv ein Zweig des Zweigs des freigegebenen Ordners.

Wenn Bob fertig ist, geht er zurück zum Kofferraum. Dies wird fortgesetzt, ohne andere Projekte zu beeinträchtigen, die möglicherweise auch einen "internen Zweig" aus dem freigegebenen Stammordner erstellt haben. Wir veröffentlichen schließlich unser Produkt, stellen jedoch fest, dass wir generische Änderungen an Common_Code vorgenommen haben, von denen andere Projekte profitieren würden. Nach einer Gruppenüberprüfung stimmen wir zu, die Version von Common_Code des Projekts wieder mit der Root-Version zu verbinden, von der die ursprüngliche Version stammt. Dies entkoppelt die Notwendigkeit, freigegebenen Code für eine Veröffentlichung zu aktualisieren, und die Notwendigkeit, die Änderungen mit dem Rest der Firma zu teilen.

Dies scheint eine einfache, aber flexible Möglichkeit, Code nativ zu teilen. Ich sehe zwei mögliche Einschränkungen. Erstens wird es nicht über Repositories hinweg funktionieren, in diesem Fall müssen externe Daten verwendet werden. Zweitens, Sie können den ersten Zweig nach der Zusammenführung nicht löschen, daher glaube ich nicht, dass -integrate verwendet würde. Ich bin mir immer noch nicht sicher, ob ein normales Zusammenführen akzeptabel wäre oder ob unser Tortoise-Client dies unterstützt.

Answer 1

Nach mehr Forschung und viel Diskussion haben wir uns entschieden, bei der externen Methode des Code-Sharing zu bleiben. Ich poste den Abschlussbericht, damit andere von den Rechtfertigungen profitieren können, die wir identifizieren konnten. Wenn die Leute denken, dass dies anderen hilft, stimmen Sie bitte so ab, dass es gesehen werden kann.

Ich ging zurück und überprüfte die unsere Schwester-Site-Politik für externe und versuchte dann, die wesentlichen Unterschiede zwischen diesen beiden Methoden zu destillieren. Eine Sache, die ich anfangs nicht erkannte, war, dass sie eine Methode zur Aktualisierung von External beschreiben, die ohne die Notwendigkeit eines Stammes und von Zweigen auf den gemeinsamen Ordnern durchgeführt werden kann - was für mich ein großes Negativ war, das wegging. Die Unterschiede sind dann nur auf diese:

Externe Methode können Sie auf eine gemeinsame Ordner-Revision, wenn gewünscht, aber wenn Sie gemeinsamen Code ändern möchten, müssen Sie aufheben, aktualisieren auf die neuesten rev lokal, hinzufügen Ihre eigenen Änderungen und Commit zurück in den gemeinsamen Ordner. Mit anderen Worten, alle arbeiten in den öffentlichen Bereichen am Kofferraum - aber mit den Stiften können Sie nicht beeinträchtigt werden, bis Sie eine Änderung vornehmen möchten. Es hält das Gemeinsame synchron, indem es eine Ebene der Trennung zwischen Ihrem projektspezifischen Code und dem Common, das es verwendet, hinzufügt.

Der doppelte Zweig ermöglicht es Ihnen, den lokalen Code lokal einzeln zu ändern. Sie müssen jedoch daran denken, ihn später wieder in den gemeinsamen Stamm einzufügen.In gewissem Sinne geht es andersherum - es hält den projektspezifischen und gemeinsamen Code immer synchron zu allen Zeitpunkten und Zweigen, fügt jedoch eine Ebene der Trennung zwischen der Projektversion von common und dem gemeinsamen common hinzu.

Eine praktische Konsequenz dieser Unterscheidung ist, dass Sie für externe Benutzer gezwungen sind, den gemeinsamen Code zuerst (beim Festschreiben) zu verschmelzen und dann in Ihrem Projektstamm zu verschmelzen. Aber andere Projekte bleiben allein, da sie an frühere Versionen gebunden sind. Auf der anderen Seite ermöglicht doppelte Verzweigung, dass Sie zuerst in Ihren Projektstamm zusammenführen und dann den gemeinsamen Code später zusammenführen (zweite Zusammenführung). Obwohl Sie es in beiden Fällen tun könnten.

Wir hatten die Idee entwickelt, dass Projekte beide Methoden wählen sollten, aber jemand wies zu Recht auf die Vorteile hin, so weit wie möglich an einer einheitlichen Politik festzuhalten. Wenn ich jetzt eines wählen müsste, würde ich mit der Methode "externals" fortfahren, weil es scheint, dass der geteilte Code durchgesetzt werden sollte, um im gesamten Repository konsistent zu bleiben. Indem es ein solches Maß an Unabhängigkeit von den spezifischen Projekten erhält, zwingt es die Menschen dazu, darüber nachzudenken, sicherzustellen, dass der gemeinsame Code generisch genug bleibt, um verwendet zu werden. Wenn irgendjemand es wirklich für den Projektgebrauch anpassen wollte, sollte es eine separate Kopie der benötigten Dateien machen und es im Projektverzeichnis machen. In diesem Fall besteht keine Absicht, in das ursprüngliche Verzeichnis zurückzukehren, so dass diese Tür nicht geöffnet werden muss.