CFD Online Logo CFD Online URL
Home > Forums

Ideas on managing a repository that supports several OpenFOAM versions

Register Blogs Members List Search Today's Posts Mark Forums Read

Rate this Entry

Ideas on managing a repository that supports several OpenFOAM versions

Posted November 1, 2014 at 13:17 by wyldckat

It's been some time since I last blogged something about OpenFOAM. Most of my free time that I allocate to OpenFOAM-related topics has been more oriented to helping out on the forum and to write the most that I can on the unofficial OpenFOAM wiki: - and Twitter is a bit quicker to micro-blog about stuff, so check out my Twitter feed as well:

Anyway, today I received a question through a private message asking about ideas on how to organize a source code repository for a toolkit that supports more than one OpenFOAM version. Here's the essentially the answer I sent the forum member.


Let me see if I can find a good example in the repositories I have...
OK, this one looks good:

If you look at this page: - you'll see an interactive diagram of how the branches are organized:
  • The "master" branch only has a "" file. There I can write the instructions for accessing any of the ports.
  • The "of21x" branch was the original "master" branch, which I later renamed so that it was exclusive for 2.1.x.
  • Then the other branches derive from the "of21x" branch on need-only-basis:
    • "of210" derived from "of21x", when I needed a branch to have adjusted the code to work on OpenFOAM 2.1.0.
    • "of22x" derived from "of21x" as well, at a point in the code where OpenFOAM 2.2.x appeared. This was useful because it meant I only had to do some modifications and makes it easier to notice what changes between versions.
Now, this arrangement has a few advantages and disadvantages:
  • The "master" branch acts almost as a 1-page wiki, that explains how to use this repository and respective branches. There is no need to merge other branches with this one, since the other threads can simply have their own README files.
  • Fixes made on one branch might have to manually be adapted to another branch, but they could also be "git cherry-pick"ed, instead of merged.
« Prev     Main     Next »
Total Comments 0



All times are GMT -4. The time now is 16:21.