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
+
/
Verwaltung mehrere Projekte und gemeinsamer Bibliothek in Subversion
