2009-04-29 6 views
2

Ich habe einige Projekte, die auf angepasster Hardware laufen. Jetzt hat sich die Hardware geändert, was einige Softwareänderungen erforderlich machte. Daher gibt es Quelle A für "alte Hardware" und Quelle B für "neue Hardware", die zu 95% gleich sind.Wie man etwas unterschiedliche Software behält?

Wenn ein neues Feature in der Zukunft hinzugefügt wird, muss es für beide Versionen durchgeführt werden. Mit anderen Worten, A und B werden Seite an Seite existieren und von nun an werden immer dieselben Änderungen erforderlich sein.

Ich habe gerade begonnen, Subversion zu verwenden, daher kenne ich mich mit all den Möglichkeiten nicht aus.

Wie ich verstehe, würde ein neuer Zweig für B beide von diesem Punkt an trennen, was ich nicht brauche.

Was ist der beste Weg, um A und B so zu pflegen, dass zukünftige Änderungen für beide Versionen gelten, ohne sie manuell zweimal anwenden zu müssen?

Antwort

3

Wenn möglich, würde ich eine einzelne Quellstruktur verwalten und #ifdefs verwenden, um den Code für den jeweiligen Prozessor anzupassen (vorausgesetzt, Sie verwenden C oder C++). Dies funktioniert besonders gut, wenn Sie die hardwareabhängigen Teile in eine kleine Anzahl von Dateien isolieren können. Wenn Sie dies tun können, ist keine zusätzliche Subversion Magie erforderlich.

+0

Das ist die gleiche Art, wie ich diese Dinge vorher gemacht habe, ohne an Subversion zu denken. Könnte sein, dass es eine bessere Lösung mit Subversion gab, das war mein Grund für die Frage. – Holgerwa

+2

Mit ifdefs innerhalb des Codes, um einen "gemeinsamen" Code-Basis-Speicherort zu pflegen, ist nicht so einfach, wie es aussehen könnte und ich kann es nicht empfehlen.Am Ende wird es eine weitere wichtige Quelle für Change Control Albtraum sein, denn es ist einfach, dass im selben Quellcode, Nebenwirkungen "Cross" Versionen einzuführen. Je mehr "Zweige" Sie haben, desto problematischer ist es, die Änderungen für eine bestimmte Version zu verfolgen und die Nebenwirkungen für die restlichen Versionen auszublenden. –

+0

@Catalin Pitis: Für jede einzigartige Hardware-Umgebung muss es zumindest einige Verzweigungen des Codes geben. IMHO, sollte man versuchen zu isolieren, was so einzigartig wie möglich ist, und vorzugsweise sammeln Sie es an einem Ort. Manchmal funktioniert #ifdefs gut, manchmal ist es sinnvoll, einige hardwarespezifische Treiberklassen oder Funktionen zu erstellen. Was empfehlen Sie als Alternative? –

0

In SVN können Sie Zweige für "alte" und "neue" Hardware erstellen.

+0

Aber müsste ich "alt" und "neu" separat auschecken und manuell eine Änderung an beiden vornehmen? – Holgerwa

+0

Ja, Sie müssten es auf diese Weise tun: Alt ändern und dann Änderungen manuell auf Neu anwenden. –

9

Ich sehe keine Notwendigkeit für eine anspruchsvolle Versionierung. Nur Ihre Quellen in Struktur wie folgt organisieren:

Project 
|-CommonSource95% 
|-HardwareA 
|-HardwareB 

Makefiles oder #ifdefs den Code für die jeweilige Hardware anpassen.

1

Isolieren Sie den Code, der für eine bestimmte Hardware-Version irgendwie ist: Stellen Sie es in verschiedene Funktionen oder verwenden Sie ein Makro, um die verschiedenen Teile auszutauschen. Dies nennen die High-Level-Betriebssysteme "Gerätetreiber".

Ermitteln Sie in der Build-Datei oder zur Laufzeit, welche Version Sie benötigen und aktivieren Sie sie. Funktionszeiger sind dein Freund.

Factor gemeinsamen Code aus und verwenden Sie es aus beiden Versionen. Auf diese Weise reduzieren Sie die Codeverdopplung, Sie können beide Versionen gleichzeitig sehen. Wenn Sie dies mithilfe von SVN-Revisionen trennen, wäre dies nicht möglich.

0

Ich würde dies nicht lösen, indem Sie in Ihrem Versionskontrollsystem verzweigen. Die Verzweigungen können zu einem Punkt divergieren, an dem es schwierig wird, Änderungen zwischen ihnen zu übertragen.

Diese Frage erinnerte mich an das Projekt Apache Portable Runtime. Sie können dieselbe Idee für Ihren Code verwenden: Verbergen Sie die Implementierungsunterschiede für verschiedene Hardware hinter einer Hardware Abstraction Layer. Die verschiedenen Implementierungen dieser Schicht können nebeneinander im selben Stamm leben. Der Großteil des Codes sollte sich nicht um die Hardware kümmern und über die HAL darauf zugreifen.

Verwandte Themen