Multiprozessor SVN Struktur

[Matthias (Gast)]

Hallo zusammen,

ich wollte euch Fragen, wie ihr eure Toolchain und Projektordnerstruktur 
aufsetzt, wenn euer Projekt mehrere Prozessoren enthält und deren Code 
auch gemeinsame Libs nutzen.

Auf welcher Ebene sind die Prozessoren gleich? Und auf welcher Ebene 
trennt ihr in trunk/branches/tags?

Wie bündelt und versioniert man für ein Gesamt-Release die Revisionen 
der verschiedenen Prozessor-Teilprojekte?


Mein Vorschlag:
---------------

Projekt/
|
+- Prozessor1/
|  |
|  +- trunk/
|  |  |
|  |  +- source/
|  |     |
|  |     +- Library (svn external)
|  |
|  +- tags/ ... 
|
+- Prozessor2/
|  |
|  +- trunk/
|  |  |
|  |  +- source/
|  |     |
|  |     +- Library (svn external)
|  |
|  +- tags/ ... 
|
+- Library/
   |
   +- trunk/
   |  |
   |  +- source/
   |
   +- tags/ ...

Habt ihr best practices?


Vielen Dank!
Matthias

[Borislav B. (boris_b)]

Matthias schrieb:
> wenn euer Projekt mehrere Prozessoren enthält

Hä?

[Matthias (Gast)]

Ein Produkt, mehrere Baugruppen, mehrere diskrete Mikroprozessoren. 
Jeder enthält Software und mir gehts um deren Struktur in SVN.

[Hans Ulli K. (Gast)]

Du meinst wahrscheinlich wenn du ein Projekt hat, dsa auf verschiedene 
Prozessoren laufen soll. Und wo sich der Code zum Teil aus spezifischen 
(ARCH) und den anderen Teil bildet ?

Dann schau mal auf kernel.org vorbei. Die machen das in etwa so

arch-+-arm
     +-mips
     +-x86

dev-+-net
    +-pci
    +-usb

.usw

Ob da jetzt SVN die richtige Lösung ist weis ich nicht.
Jedenfalls habe uch da vor ca. 3-4 Jahren damit aufgehört zu arbeiten, 
als ich die ersten Branches mergen wollte.
Danach habe ich ca. 1 Jahr gebraucht im den Quatsch von SVN mir aus dem 
Hirn zu drücken und bin dann auf GIT umgestiegen.

[Stefan R. (srand)]

Hans Ulli Kroll schrieb:
> Du meinst wahrscheinlich wenn du ein Projekt hat, dsa auf verschiedene
> Prozessoren laufen soll.

Oder halt ein Produkt, das mehrere (verschiedene) Prozessoren enthält.

[Walter T. (nicolas)]

Oder geht es ganz allgemein um die Nutzung gemeinsamer Libraries mit 
unterschiedlichen SVN-Projekten?

[Matthias (Gast)]

Sowohl als auch :) Ich glaube die gemeinsame Library in einem Ordner zu 
haben und per svn:externals einzubinden ist nicht verkehrt!?

[Vn N. (wefwef_s)]

Matthias schrieb:
> Ein Produkt, mehrere Baugruppen, mehrere diskrete Mikroprozessoren.
> Jeder enthält Software und mir gehts um deren Struktur in SVN.

[tag/branch/trunk]
|
+---Prozessor 1 
|        |
|        |-src
|        |-bin
|        ...
|
+---Prozessor 2
|        |
|        |-src
|        |-bin
|        ...
|
+---common

Ist einfach deshalb ungemein sinnvoll, weil zumindest bei uns die 
Prozessoren immer auf der selben Softwarerevision laufen sollten (und 
dies auch beim booten prüfen). Bei deinem Vorschlag könnten beide 
Prozessoren unterschiedliche Versionen besitzen (was vieleicht im 
konkreten Fall auch kein Problem ist).

Hans Ulli Kroll schrieb:
> Du meinst wahrscheinlich wenn du ein Projekt hat, dsa auf verschiedene
> Prozessoren laufen soll. Und wo sich der Code zum Teil aus spezifischen
> (ARCH) und den anderen Teil bildet ?
>
> Dann schau mal auf kernel.org vorbei. Die machen das in etwa so
>
> arch-+-arm
>      +-mips
>      +-x86
>
> dev-+-net
>     +-pci
>     +-usb
>
> .usw

Nein, er meint beispielsweise ein Produkt, welches sowohl einen DSP für 
berechnungen als auch einen ARM zur Kommunikation besitzt. Und als 
draufgabe vielleicht noch ein FPGA.
Für mögliche Hardwareversionen ist alldings bei uns auch ein 
"arch"-Ordner vorgesehen, der den HAL zur verfügung stellt.

Hans Ulli Kroll schrieb:
> Ob da jetzt SVN die richtige Lösung ist weis ich nicht.
> Jedenfalls habe uch da vor ca. 3-4 Jahren damit aufgehört zu arbeiten,
> als ich die ersten Branches mergen wollte.
> Danach habe ich ca. 1 Jahr gebraucht im den Quatsch von SVN mir aus dem
> Hirn zu drücken und bin dann auf GIT umgestiegen.

Ja, mergen ist immer ein Krampf. Die eingebaute Mergefunktion fasst auch 
gern mal Dateien an, ohne vorher nachzufragen oder auch nur eine Meldung 
auszugeben, dass diese angefasst wurden. Leider scheint es keine 
Funktion zu geben, bei der man wirklich bei jeder einzelnen 
unterschiedlichen Datei aufgefordert wird, diese manuell per Diff-View 
zu vereinigen.

[Matthias (Gast)]

vn nn schrieb:
> [tag/branch/trunk]
> |
> +---Prozessor 1
> |        |
> |        |-src
> |        |-bin
> |        ...
> |
> +---Prozessor 2
> |        |
> |        |-src
> |        |-bin
> |        ...
> |
> +---common
>
> Ist einfach deshalb ungemein sinnvoll, weil zumindest bei uns die
> Prozessoren immer auf der selben Softwarerevision laufen sollten (und
> dies auch beim booten prüfen). Bei deinem Vorschlag könnten beide
> Prozessoren unterschiedliche Versionen besitzen (was vieleicht im
> konkreten Fall auch kein Problem ist).

Danke für die Antworten! Ich glaube bei uns wird eine modulare/parallele 
Entwicklung im Vordergrund stehen. Deshalb wird tag/branch/trunk weiter 
nach hinten reingezogen.
Die Versionierung der Einzelkomponenten kann man doch in einem extra 
Ordner machen und dort mit svn:externals die Kombinatorik definieren!?


vn nn schrieb:
> Nein, er meint beispielsweise ein Produkt, welches sowohl einen DSP für
> berechnungen als auch einen ARM zur Kommunikation besitzt. Und als
> draufgabe vielleicht noch ein FPGA.

Korrekt! Mehrprozessorsystem, das als ganzes unser Produkt darstellt.

[Hans Ulli K. (Gast)]

vn nn schrieb:
> Ja, mergen ist immer ein Krampf. Die eingebaute Mergefunktion fasst auch
> gern mal Dateien an, ohne vorher nachzufragen oder auch nur eine Meldung
> auszugeben, dass diese angefasst wurden. Leider scheint es keine
> Funktion zu geben, bei der man wirklich bei jeder einzelnen
> unterschiedlichen Datei aufgefordert wird, diese manuell per Diff-View
> zu vereinigen.

Das ist git (etwas) besser [1].
Das mergen geht hier einfach zur Hand. Es werde auch nur die Files 
"angeboten" die git nicht alleine mergen konnte. Diese sind auch nur 
noch in "git diff" bzw. "git difftool" zu sehen, die anderen werden 
ausgeblendet.
Die automatischen merges kann man sich zu Beginn auch noch ansehen,
"git diff --cached" bzw. "git difftool --cached"

[1]
Beim mergen wird der jeweilige "Vater" im 3 Fenster Diff (meld, kdiff3) 
und seine zwei Söhne mit angezeigt.
Es kann aber vorkommen, das die Branches soweit divergiert sind, das aus 
dem Vater denn der UrUrGroßvater geworden ist. Das ist denn beim 
erstenmal etwas gewöhnungsbedürftig.