Best Practices für die Entwicklung und Verwendung gemeinsamer Bibliotheken in der Versionskontrolle?

Question

Ich habe mich immer gefragt, wie eine aktiv entwickelte gemeinsame Bibliothek in zwei oder mehr Projekten in der Versionskontrolle gespeichert werden sollte. Ich kann mir vorstellen, dass es anders gehandhabt werden kann als eine Drittanbieter-Bibliothek, da eine interne Bibliothek eher Hotfixes erhält, die an viele Projekte in der Versionskontrolle verteilt werden sollten.

Sollten die binären Dateien in die Projekte importiert werden, die sie verwenden, während sie aktualisiert werden (so ziemlich wie eine Bibliothek eines Drittanbieters), oder könnte ihr Quellcode zusammen mit den Projekten ausgecheckt werden? Ist es möglich, Referenzen auf andere versionsgesteuerte Pfade in Subversion oder anderen Versionskontrollsystemen zu haben?

Ich arbeite jetzt in einem Projekt, das gemeinsame Bibliotheken hat, die an anderer Stelle in Subversion (und in vielen Projekten verwendet) mit dem Projekt eingecheckt sind, so dass Änderungen an ihnen in diesem Projekt nicht in ihrem "echten" widerspiegeln " Repository. Ich werde einige Änderungen vorschlagen, aber ich hätte gerne ein paar Gedanken darüber, was die beste Vorgehensweise für die Handhabung dieser allgemeinen Bibliotheken ist.

Answer 1

Wie andere haben bereits erwähnt, SVN's externals sind ein guter Weg, dies zu tun. Durch sie können Sie auf andere Teile Ihres Repositories (oder auch anderer Repositories, FTM) verweisen. Ein Projekt kann auf den Kopf eines anderen (Bibliotheks-) Projekts oder einer Verzweigung oder eines Tags verweisen. Die beiden letztgenannten sorgen für Stabilität, die erste für immer auf dem neuesten Stand der Bibliothek.

Ich habe entlang dieser Linie mit CVS verschiedenen Schemata gesehen (hier keine Äußerlichkeiten, so war es ausgecheckten in Skripten, die ausgeführt werden mußten) und SVN. In der Firma, in der ich arbeite, haben wir verschiedene Ordner auf der obersten Ebene für Projekte und gemeinsame Bibliotheken. Die Projekte können die Bibliotheken referenzieren. Auf dem Stamm des Projekts beziehen sich diese externen Referenzen normalerweise auf die Köpfe der Bibliotheken, auf Tags und Zweige beziehen sich die Projekte auf die Tags der Bibliotheken (oder manchmal Zweige).

Answer 2

Wenn ich Subversion verwende, würde ich svn:externals verwenden, mit denen Sie Abhängigkeiten von einem Subversion Repo zu einem anderen erstellen können.

Answer 3

In Subversion können Sie Referenzen auf andere Pfade verwenden, indem Sie die svn:externals-Eigenschaft verwenden.

Das heißt, oft möchten Sie ein wenig mehr Kontrolle über den Zustand eines Projekts als nur "nehmen, was auch immer in der Shared Library Kopf ist". In diesem Fall würde ich vorschlagen, die kompilierte Bibliothek in jedes der anderen Projekte zu übertragen, die sie verwenden. Auf diese Weise haben Sie die Kontrolle über die Bereitstellung der Bibliothek für jeden einzelnen Client.

Answer 4

Ja.

Trennen Sie wiederverwendbare "Unterbibliotheken" früh und oft in separate Projekte.

Betrachten Sie Open-Source-Praktiken: Die meisten Dinge sind viele kleine Projekte, die zusammengefügt werden.

Erstellen Sie viele kleine Projekte.

Vermeiden Sie das Einchecken von Binärdateien. Folgen Sie erneut Open-Source-Praktiken. Quelle in Subversion halten.

Erstellen Sie Binärdateien und legen Sie sie in ein "Projektfreigabe" -Verzeichnis getrennt von der Quelle.

Answer 5

Das richtige Werkzeug für dieses Problem ist Maven. Ursprünglich für Java entwickelt, kann es für jede vorhandene Programmiersprache verwendet werden.

Maven erstellt auf Ihrem Computer ein Repository, in dem sich alle Module befinden. Sie können auch ein öffentliches Modul-Repository erstellen, sodass andere Personen Module von dort herunterladen können.

Jedes Modul verfügt über eine Liste von Abhängigkeiten, die automatisch aufgelöst werden (Download gelesen). In der Build-Phase des Projekts wird ein für Ihre Programmiersprache passendes Plugin alle Abhängigkeiten an bestimmte Stellen setzen, damit der Quellcode sie sehen kann.

Maven ist ein großartiges Multifunktionswerkzeug, aber es ist sehr schwer zu meistern, das ist nur Minus.

Answer 6

Wir behalten den Code von allgemeinen Bibliotheken in SVN in ihren eigenen Projektordnern. Wir binden die Binärdateien auch in einen anderen "Projekt" -Ordner namens Abhängigkeiten. Wir verwenden svn: externals, um die benötigten Referenzen in Projekte zu bringen.

Answer 7

Ich verstehe nicht einmal die Frage. Wenn foo von libbar abhängt, warum willst du die Quelle für libbar in foos VCS behalten? Sie verknüpfen sich mit der libbar oder importieren das Barmodul, wenn es für die Sprache geeignet ist. Warum möchten Sie den Quellbaum für Ihr Projekt durcheinander bringen? Mein "Hallo, Welt!" Projekt hängt von libc ab. Also mein "Hallo, Dolly!" Projekt. Keines der Projekte behält die libc-Quelle in ihrer Codebasis. Dies zu tun wäre verrückt. Warum sollten interne Bibliotheken anders behandelt werden als Drittanbieter-Bibliotheken in dieser Hinsicht? Kurz gesagt, die beste Vorgehensweise ist: Tu es nicht. Wenn Ihre Bibliothek Hotfixes enthält, die an Ihre Projekte weitergegeben werden müssen, verwenden Sie die dynamische Verknüpfung.