Version control for multiple instances of a developing code

Question

I work in an engineering lab, not a computer science lab. As such, our in-house software is not the deliverable product. Instead, the in-house software is used to analyze engineering problems, and we deliver the results.

This makes version control a living hell. Or perhaps I should just say that the standard "trunk and branch" version control tree structure doesn't seem to apply. I'm hoping someone can suggest a better way of doing things.

For example, each engineering project requires adding case specific input files, run-time files, and post-processing files. None of these really belong in trunk, because they aren't general, but each new project needs these files. We tried putting templates in trunk but there was no clear best practice as to when templates should be merged up.

Similarly, the in-house code is always evolving as we add new capabilities. Many of these should be merged into trunk so they will be available for future applications. However, there are also quite a few case-specific hacks which the trunk doesn't need to see.

How should we organize this mess? Obviously, the simpler the better.

Answer 1

We really try for our projects to keep separate:

• source files (managed in any VCS of your choice, like SVN)
• configuration files (specific to a team or an environment)

Branches are for development effort and those "input files, run-time files, and post-processing files" will evolve at their own pace.

For that kind of file, what we managed in a VCS are:

• templates
• scripts able to take that template and generate the (private, as in not versioned) config file with the right values in it.
  The values come from another referential, like a database, where the teams (or environment administrators) can update them at will, without any concern about checkout/check-in/merge.
  That database can then be versioned in its own VCS if needed (see this SO question for instance, or, as an alternative, that one)

Answer 2

In engineering version control is often underestimated whereas it is essential to restore given settings in order to repeat experiments. For general adoption easy to use, mostly GUI oriented, tools help a lot.

Leveraging version control with issue tracking that relates issues to code commits increases productivity tremendously.

Concerning repository structure, at least looking at subversion, there are just conventions but no strict rules imposed by the tool. What about having a tree called 'trunk' where all 'common code' is managed.

For every engineering task there is a branch created. Which is nothing else than a 'project folder' with version control. Source code relevant to other projects will be merged back to trunk.