2010-12-13 9 views
2

Ich bin an einem Projekt arbeiten, wo wir Signalverarbeitungsalgorithmen mit MATLAB Prototyp, und sie dann auf einem Embedded-Controller in C implementierenWorkflow für die parallele Entwicklung von Prototyp-Code und seiner Implementierung in C

Wir sind noch in den frühen Phasen des Projekts, und wir erforschen immer noch alternative Algorithmen. Wir erhalten auch Feedback von den Controller-Tests, die die Weiterentwicklung unserer MATLAB-Prototypen beeinflussen.

In this related question stellte sich die Frage, wie das SVN-Repository strukturiert werden sollte, um die parallele Entwicklung von Prototypen und die reale Implementierung zu unterstützen. In den Antworten wurde jedoch nicht auf den Entwicklungsablauf eingegangen.

Zum Beispiel haben wir in unserem aktuellen Projekt entschieden, dass nur Prototyp-Code auf dem Stamm übergeben werden kann, während Implementierungscode in einem dedizierten Zweig übergeben werden muss.

Ich würde gerne Ihre Erfahrung in der Verwaltung der Workflow einer parallelen Entwicklung von Prototyp-Code und seiner Implementierung zu hören.

Antwort

0

Meine Antwort reflektiert meine Erfahrung, nicht irgendeine "allgemeine Wahrheit" (was immer das sein mag).

In einem Projekt, an dem ich gerade arbeite, gibt es keinen dedizierten Branch/Tag für Prototyping vs. Implementierung. Der Prototyping-Code hat seinen eigenen Ordner (z. B. research) und die Implementierung einen eigenen Ordner (dev), und sie beide Teil des Trunks.

Was unser Versionskontrollsystem (svn) betrifft, gibt es keinen Unterschied zwischen einem "Zweig" und einem "Tag" - der Unterschied ist nur ein konzeptioneller Unterschied, oder anders gesagt, "wie Sie denken darüber'.

Nach der Definition für einen Zweig vom svn documentation:

eine Entwicklungslinie, die unabhängig von einer anderen Linie existiert, noch teilt noch eine gemeinsame Geschichte, wenn man weit genug zurück in der Zeit schauen

Ich sehe nicht, wie Prototyping/Implementierung in diese Definition fällt, da sie nicht zwei unabhängige Entwicklungslinien sind.

Normalerweise verzweige ich so wenig wie möglich, hauptsächlich, weil ich nicht auf das Versionskontrollsystem zählen will, um den Zweig korrekt zu verschmelzen.

EDIT: Natürlich ist die oben genannte Definition keineswegs "DIE Definition", es ist mehr ein vorgeschlagenes Konzept. Wenn Sie davon überzeugt sind, dass die Verzweigung der Arbeitsfluss ist, von dem Ihr Projekt am meisten profitiert, ist das ein guter Grund, es zu verwenden, auch wenn es nicht einer Definition oder einem anderen entspricht.