Wie verwaltet man externe Abhängigkeiten, die ständig geändert werden?

Question

Unsere Entwicklung verwendet viel Open-Source-Code, und ich versuche herauszufinden, wie ich diese externen Abhängigkeiten am besten verwalten kann.

Unsere derzeitige Konfiguration:

• wir entwickeln sowohl für Linux als auch für Windows
• Wir verwenden svn für unseren eigenen Code
• externe Abhängigkeiten (boost, log4cpp usw.) werden nicht in svn gespeichert. Stattdessen lege ich sie unter ./extern (oder c: \extern unter Windows). Ich möchte sie nicht in unser Repository aufnehmen, weil ich sie dann nicht mehr aktualisieren kann. Einige von ihnen werden ständig aktualisiert.

Meine Fragen

• Was ist zu tun, wenn ich externen Code ändern muss? Derzeit habe ich in meinem svn-Repository einen Ordner mit dem Namen extern_hacks angelegt, in dem ich den modifizierten externen Code ablege. Ich verlinke (oder kopiere unter Windows) die Dateien dann in die externe Verzeichnisstruktur. Diese Lösung ist problematisch, da es schwer ist, den Überblick über das Kopieren der Dateien zu behalten, und es sehr schwer ist, die Dateien von svn aus zu aktualisieren, wenn sie in zwei Repositories liegen (meinem für die geänderten Dateien und dem ursprünglichen Repository, z.B. sourceforge)

• Wie verwaltet man die Versionen von externen Abhängigkeiten?

Ich bin gespannt, wie andere mit diesen Fragen umgehen. Danke!

Answer 1

Ich behalte sie in svn, und verwalte sie als Vertriebsniederlassungen . Wenn sie extern lose gehalten werden, ist es sehr schwierig, zu einem früheren Build zurückzukehren oder Fehler in einem früheren Build zu beheben (insbesondere wenn der Fehler auf eine Änderung der externen Abhängigkeit zurückzuführen ist).

Sie in svn aufzubewahren, hat mir viel Kopfzerbrechen erspart und ermöglicht es Ihnen auch, eine neue Workstation zu bekommen, die schnell an Ihrer Codebasis arbeiten kann.

Answer 2

Ich verstehe nicht, warum Sie sagen

Ich möchte sie nicht in unser Repository stellen, weil ich sie dann nicht mehr aktualisieren kann. Einige von ihnen werden ständig aktualisiert.

Sie müssen wirklich

1. Nehmen Sie externe Abhängigkeiten in Ihre Versionsverwaltung auf, aktualisieren Sie sie regelmäßig und testen Sie sie.

2. Koordinieren Sie Ihren Build-Prozess mit den Updates für die externen Abhängigkeiten.

Wenn Ihr Code von etwas abhängt, dann müssen Sie wirklich die Kontrolle darüber haben, wann er aktualisiert/geändert wird. Kodierung in einem Raum, in dem diese Abhängigkeiten jederzeit aktualisiert werden können, ist zu schmerzhaft, wie Sie zweifellos herausfinden werden. Ich persönlich bevorzuge Option 1.

Answer 3

Als ich so etwas tun musste, fügte ich die externe Quelle als extern hinzu und wandte dann einen Patch darauf an. Der Patch enthält meine Änderungen an der externen Quelle. Ich kontrolliere also eigentlich nur meine Patches. Meistens funktioniert das, wenn es keine "dramatischen" Änderungen im externen Code gibt.

Answer 4

Haben Sie bedacht Maven ? Es handelt sich um ein Build-System, das eine hervorragende Unterstützung für die Verwaltung von Abhängigkeiten bietet. Für jedes Projekt können Sie die erforderlichen Abhängigkeiten in einer xml-Datei als Teil dieses Projekts angeben. Die externen Bibliotheken werden in einem Dependency Repository gespeichert (in unserem Fall Artefaktfabrik ), das von Ihrem Versionskontrollsystem getrennt ist und einfach ein Netzlaufwerk sein kann. Es ermöglicht auch die Verwaltung verschiedener Versionen von Projekten.

Answer 5

Ich würde Maven mit Vorsicht genießen, denn:

• es ist ein weiteres Repository in einem System, in dem Sie bereits ein Repository mit Ihrem aktuellen Versionskontrollsystem haben;
• es (Maven) basiert auf der einzigen "gemeinsamen Versionskontrolle", die jeder Entwickler hat, dem Dateisystem (was bedeutet, dass es keine Metadaten oder Eigenschaften gibt, die an die Datei angehängt sind, keine richtige Historie in Bezug darauf, wer was und wann geändert hat)

Wenn Sie mit Drittanbietern arbeiten, können Sie diese in Ihr Versionskontrollsystem aufnehmen, aber in einer verpackte Art : sehr kompakt, mit gezippten Quellen und Dokumentationen, um die die geringstmögliche Anzahl von Dateien haben .

Auf diese Weise können Sie die Bereitstellung dieser (vielen) Bibliotheken von Drittanbietern leicht, da die Anzahl der zu verteilenden Dateien gering ist.

Außerdem können Sie einen Zweig (z. B. einen "Hack"-Zweig) erstellen, in dem Sie die gepackte (oder gezippte) Version der gehackten Bibliothek speichern.

Was Sie extern speichern können, ist der entpackte, vollständige Satz von Dateien, die diese Bibliotheken repräsentieren, da es keine wirkliche Entwicklung an ihnen gibt, oder nur einen punktuellen Hack: Normalerweise ist es nicht Ihre Aufgabe, bestehende Bibliotheken zu entwickeln, sondern sie (sogar ein wenig modifiziert) für die schnellere Implementierung einiger Funktionen Ihres Projekts zu verwenden.

Wenn Sie irgendwann eine gehackte Version mit einer offiziellen Version vergleichen müssen, ziehen Sie einfach die entsprechende "gehackte" Versionsnummer aus svn heraus, entpacken sie und vergleichen sie mit der offiziellen (und extern gespeicherten) Version (zum Beispiel mit winmerge)