Verwaltung mehrere Projekte und gemeinsamer Bibliothek in Subversion

Hallo LV-Gemeinde,

in der Firma möchten wir in Kürze auf eine Versionsverwaltung umsteigen, haben uns bei unseren Überlegungen oder Ansätzen allerdings immer in eine Sackgasse manövriert. Das Problem genau genommen besteht darin dass wir verschiedene Projektzweige habe. Alle Projekte haben aber gemein, dass sie alle auf eine gemeinsame "Bibliothek" zurückgreifen sollen. Diese stellt für sich eigentlich ein eigenes Projekt dar.

Code:

+
+
++++ Projekt A
+
+
++++ Projekt B
+
+
++++ gemeinsame Bibliothek (Projekt C)

Der Arbeitsfluss sieht nun so aus, dass ein Entwickler an dem Projekt A arbeitet. Bei diesem Prozess können/ müssen auch Änderungen bzw. Erweiterungen an die Bibliothek einfließen. Ein zweiter Entwickler arbeitet nun aber parallel an dem Projekt B und kann aktuell die Bibliotheks-Änderungen überhaupt nicht gebrauchen. Beispielsweise möchte er nur einen Bug-Fix in B vornehmen. Kurz und knapp möchte er aber dabei auf eine anderen Versionsstand der Bibliothek zurückgreifen. Nach abgeschlossener Arbeit pflegen beide Entwickler ihre Projekte in das Repository hinein. Bei beiden Commits soll natürlich in der Versionsverwaltung ersichtlich sein, welches Projekt mit welchem Stand der Bibliothek gearbeitet hat. Am nächsten Tag soll Projekt B erweitert werden und der neuen Bibliothek vom Vortag angepasst werden. Was soll passieren? Der Entwickler holt sich das Projekt vom Vortag und wechselt auf die aktuelle Version der Bibliothek, passt Projekt B entsprechend ein und schiebt es wieder in das Repo.
Unsere ersten Versuche diesbezüglichen unternahmen wird mit dem SCC-System Git. Dabei war jedes Projekt und die Bibliothek als eigenes Repository umgesetzt. Soweit so gut, allerdings bedingte dieses Modell, dass bei einem Commit in einem Projekt nicht die Versionsgeschichte der Bibliothek einfloss. Es gab keine Repo-Abhängigkeit von Projekt A/B zu der Bibliothek. Es fehlt die Info in den Projekt-Repositories in welchem Versionsstand die Bibliothek zu diesem Zeitpunkt war. Den nächste Ansatz fanden wir dann unter dem Stichwort submodules. Dies heißt, dass das Repo der Bibliothek zusätzlich in die jeweiligen Projekt-Repositories eingebunden wurde. Für LabVIEW lag damit die Bibliothek scheinbar im Projektordner. Dies erlaubte es die Bibliothek innerhalb der Projekte auf einzelne Zustände zu wechseln. Hier hatte man genau die volle Kontrolle über die Versionsgeschichte.
Eigentlich genau das was wir wollten, bis wir LabVIEW starteten. Das Problem was sich aufzeigte war, dass wenn sich ein VI in der Bibliothek veränderte auch der Pfad des VIs an die aktuelle Projektstruktur angepasst wurde. Bei absoluten Pfaden irgendwie klar. Im anderen Projekt zeigten sich dann ständig Konflikte, von wegen der Pfad des VIs hat sich verändert. Das ist echt nervig und mühsam ständig aufzulösen. Was für LabVIEW eigentlich notwendig wäre ist folgendes. Die Bibliothek müsste in der Verzeichnisstruktur für alle Projekte stets an der gleichen Stelle liegen. Genau dieser Fall wäre erfüllt, wenn wir wie oben beschrieben jedes Projekt in ein eigenes Repository aufbauen, ohne submodule etc.. Das Problem wäre dann aber wieder der Verlust der Versionsgeschichte der Bibliothek (siehe oben).

Meine konkrete Frage ist nun die, wie ihr sowas bisher gelöst habt und vor allem ob sich die Problematik vielleicht mit Subversion lösen lässt? Auf der Seite http://www.skmwiki.de/index.php/Repository_Struktur bin ich auf folgendes Modell gestossen, welches alle Projekte in einem Repository beinhaltet soll?

[code]+
+++ ProjektA
+

Hi Falk
Deine Problemstellung kann ziemlich sicher mit Subversion gelöst werden.

In jedem Fall sollten alle Projektdateien und Bibliotheken in einem Repository liegen, um die Versionshistorie im Zusammenhang und Kontext korrekt wiederzugeben.

Unter Repository-Verzeichnisse/-Dateien können natürlich als Arbeitskopie an jeweils geeigneten auch verschiedenen Stellen ausgecheckt werden.

Wenn Entwickler B an den Änderungen von Entwickler A nicht interessiert ist, bleibt er einfach bei seiner aktuellen Revision. Möchte B eine Änderung commiten, die aber nicht als neue trunk Revision erscheinen soll, um A nicht zu stören, kann B einen Branch erzeugen und seine Änderung/Bug-Fix als Branch commiten.

Zu einem späteren Zeitpunkt können die beiden Branches dann wieder zur gemeinsamen trunk-Revision gemerged werden.

Übrigens: In LabVIEW 2010 kann der VI-Objectcode getrennt vom eigentlichen VI gespeichert werden. Damit wird das Problem der relativen Pfade gelöst. Bei solchen Änderungen, die nur den Objectcode btreffen, wird nur dieser im Hintergrund recompiliert, das VI aber nicht als geändert markiert.

Gruß Holger

Übrigens: Hier ist beschrieben, wie wir Subversion an der GSI benutzen. Dort gibt es auch Links zu weiterer Hintergrundinformation von NI.