SVN: übergreifende Projekte verwalten

[Cheatah]

Hi,

vorweg: Ich bin mir nicht ganz klar darüber, wie die ideale Bezeichnung lautet. Das könnte auch der Grund sein, weshalb ich im Netz nicht fündig geworden bin ;-) aber ich finde nicht mal einen Hinweis darauf, dass schon mal jemand über dieses Problem auch nur nachgedacht hat.

Wir arbeiten glücklich[tm] mit SVN. Nun haben wir dort ein Projekt (nennen wir es "Projekt F") abgelegt, welches von anderen Projekten benutzt werden soll. An Projekt F wird kontinuierlich weiter gearbeitet, während andere die Projekte X, Y und Z beackern, in welchen F benutzt wird. (Die Dateien von F liegen mitten in denen des jeweiligen anderen Projektes, teilweise auch in Unterverzeichnissen.)

Aktuell ist es so, dass F immer innerhalb eines anderen Projektes weiterentwickelt[1] und die Änderungen mehr oder minder manuell in die übrigen Projekte überführt werden. Schöner wäre es, wenn Projekt F zwar in Projekt X weiterentwickelt würde, aber von dort (als Projekt F!) commitet wird und die Projekte Y und Z beim Update diese Änderungen automatisch übernehmen.

Hat da jemand 'ne Idee?

Cheatah

[1] Genauer gesagt gibt es momentan kein Projekt F, sondern nur gleiche Dateien bei den Projekten X, Y und Z.

[Alexander (HH)]

Moin Moin!

Für mich liest sich Dein Problem (möge es nie meines werden ;-)) wie Externals.

Alexander

[Cheatah]

Hi,

Für mich liest sich Dein Problem (möge es nie meines werden ;-)) wie Externals.

hoppla, ja, klingt gut. Jetzt muss ich da erst mal durchsteigen ... Auf den ersten Blick sieht es wie die richtige Richtung aus, könnte aber schwer integrierbar sein, zumal F zwingend im Hauptverzeichnis des Projektes liegt und insgesamt alles über diverse Verzeichnisse vermischt wird.

Aber egal, vielen Dank für diese Richtungsweisung, die ich nächste Woche umzusetzen versuchen werde. Dank geht natürlich auch an Daniel :-)

Cheatah

[Daniel Thoma]

Hallo Cheatah,

Wir arbeiten glücklich[tm] mit SVN. Nun haben wir dort ein Projekt (nennen wir es "Projekt F") abgelegt, welches von anderen Projekten benutzt werden soll. An Projekt F wird kontinuierlich weiter gearbeitet, während andere die Projekte X, Y und Z beackern, in welchen F benutzt wird. (Die Dateien von F liegen mitten in denen des jeweiligen anderen Projektes, teilweise auch in Unterverzeichnissen.)

Bei X, Y und Z handelt es sich aber nicht um eine Art Branches von Z?
Wenn das der Fall ist, könnte eine Lösung sein, einfach im selben Repository Branches anzulegen.
Nun kann es natürlich sein, dass es von der Struktur her Branches sind, von der organisatorischen Seite her allerdings unabhängige Projekte und daher ein gemeinsames Repository problematisch oder unmöglich ist.
In dem Fall seid ihr an die Grenzen von SVN gelangt. Ihr bräuchtet private Branches (also Branches eines Repositories A in einem Repository B). So etwas geht mit verteilten Versionsverwaltungssystemen (Mercurial, GIT, ...). Oft können diese auch zumindest Revisionen aus SVN holen oder sogar Änderungen zurückspielen (was euch aber ja nicht interessiert).
Es wäre also vielleicht möglich, X, Y und Z mit einem verteilten VCS zu verwalten. (Man kann natürlich auch gleich wechseln, aber das ist natürlich ungleich aufwändiger und evtl. gibt es da wieder unüberwindbare organisatorische Hürden).

Handelt es sich hingegen nicht um Branches, würde ich sagen, ihr habt eine kaputte Architektur.
Die Sourcen verschiedener Projekte sollten sauber getrennt sein. Selbst wenn es aus irgend welchen technischen Gründen notwendig ist, diese zusammen zu führen, sollte das besser durch einen (automatisierten) Buildprozess passieren aber nicht schon im Repository.

Grüße

Daniel

[Cheatah]

Hi,

Bei X, Y und Z handelt es sich aber nicht um eine Art Branches von Z?

nein, es sind eigenständige Projekte, die lediglich die selbe Basis besitzen  (nämlich F). Ähnlichkeiten zwischen X, Y und Z gibt es ansonsten keine.

Handelt es sich hingegen nicht um Branches, würde ich sagen, ihr habt eine kaputte Architektur.

Nö. "F" steht für "Framework" ;-)

Die Sourcen verschiedener Projekte sollten sauber getrennt sein.

Zustimmung. Im Idealfall ist F auch nicht bei X, Y und Z mit eingecheckt, aber bei sowas beuge ich mich den technischen Bedingungen.

Cheatah

[Daniel Thoma]

Hallo Cheatah,

nein, es sind eigenständige Projekte, die lediglich die selbe Basis besitzen  (nämlich F). Ähnlichkeiten zwischen X, Y und Z gibt es ansonsten keine.

Das ist ja nicht notwendig. Unter "Branch" hätte ich jetzt verstanden, dass die zu Grunde legende Software irgendwie angepasst wird und nicht einfach nur verwendet.

Nö. "F" steht für "Framework" ;-)

Aber auch bei Frameworks werden normalerweise nicht die Dateien vermischt.
Die Verflechtung mit dem Framework passiert ja normalerweise zur Laufzeit oder Compilezeit bzw. beim Deployment eben z.B. durch Mechanismen wie Vererbung oder meinetwegen auch durch irgendwelche Protokolle.

Zustimmung. Im Idealfall ist F auch nicht bei X, Y und Z mit eingecheckt, aber bei sowas beuge ich mich den technischen Bedingungen.

Was spricht dagegen, wirklich eine Art Buildprozess auszuführen, der irgendwo außerhalb der Arbeitskopie die verschiedenen Komponenten zusammenbaut?

Generell würden Mercurial etc. den "aus mehreren Quellen auschecken"-Ansatz unterstützen.

Grüße

Daniel

[Mega]

Hat da jemand 'ne Idee?

Die einzige Idee, die mir einfällt, ist ein Hookscript, das beim Commit von X, Y und Z automatisch nach F merged und F damit immer auf dem aktuellen Stand hält, den auch X, Y und Z haben.

Dazu müsstest du im Hookscript natürlich auswerten, ob die Datei zu Projekt F gehört oder nicht. Dürfte mit einer einfachen Liste zu realisieren sein.

Ich hab zwar mal mit einer Versionskontrolle gearbeitet, die dein problem lösen könnte, die kostet aber richtig Kohle und ist recht kompliziert zu handeln. Wenn du an sowas Interesse hättestm könnte ich aber nochmal nachfragen, wie das Ding heisst. Ich habs mir nicht gemerkt.

[Tim Tepaße]

Hallo Cheatah,

ich bezweifele zwar, dass Du eine Änderung des Versionskontrollsystems durchsetzen könntest, aber der Vollständigkeit noch mal nachgereicht: git-submodule(1).

Tim