Workflow for parallel development of prototype code and its implementation in C

2
votes

I'm working on a project where we prototype signal-processing algorithms with MATLAB, and then implement them on an embedded controller in C.

We're still in the early stages of the project, and we're still exploring alternative algorithms. We're also getting feedback from the controller tests that inform the further development of our MATLAB prototypes.

In this related question, the question was how to structure the SVN repository to support the parallel development of prototypes and the real implementation. However, the answers that were given did not address the issue of the development workflow.

For example, in our current project we have decided that only prototype code can be committed on trunk, whereas any implementation code must be committed on a dedicated branch.

I'd like to hear your experience in managing the workflow of a parallel development of prototype code and its implementation.

1
matlabprototypemethodology

1 Answers

0
votes

My answer reflects my experience, not any 'general truth' (whatever that be).

On a project I'm working on now, there is no dedicated branch/tag for prototyping vs. implementation. The prototyping code has its own folder (named e.g, research) and the implementation its own folder (dev), and they both part of the trunk.

As far as our version-control system (svn) is concerned, there is no difference between a 'branch' and a 'tag' - the difference is just a conceptual difference, or in other words, 'how you think about it'.

Following the definition for a branch from the svn documentation:

a line of development that exists independently of another line, yet still shares a common history if you look far enough back in time

I don't see how prototyping/implementation falls into this definition, since they are not two independent lines of development.

I usually avoid branching as much as I can, mainly since I do not want to count on the version-control system to do the merging of the branch correctly.

EDIT: Of course the definition cited above is by no means 'THE definition', it is more a suggested concept. If you are convinced that branching is the work-flow from which your project will benefit the most - that's a good enough reason for using it, even if it doesn't conform to one definition or anopther.