We’ve been very busy here over the last few weeks with Voxeliens related things so I though I should send an update on what’s been going on in the area of PolyVox. There’s been two main changes recently which I hope will help make things easier for people as we move forward.

CMake Folders

The first thing we’ve done is to start using a nice little feature of CMake to make working in Visual Studio a little nicer. Before this change, the Solution Explorer looked like:

Obviously, this is a little hard to work with since all the tests, as well as internal targets like ZERO_CHECK and _PolyVoxCore are included in the list. What would be ideal is if it were possible to organise the targets into a hierarchy which matches how the code is logically organised. I found a blog post showing how CMake can do this. First of all, you must enable a global CMake property to turn on this feature.

set_property(GLOBAL PROPERTY USE_FOLDERS ON)

Then, for each CMake target, you mush set a property which defines the “folder” in which it will appear. For example, for the PolyVoxCore target, we add the following line to its CMakeLists.txt file:

set_property(TARGET PolyVoxCore PROPERTY FOLDER "library/PolyVoxCore")

Once these are added to all the targets you want to categorise, you will see something more like this in Visual Studio:

Which has put everything in a more logical place. This was added to Git a few weeks ago in this commit.

Git Branching Model

The second “feature” we’ve recently added is a new way of working with our Git repository. Up until now, we’ve simply done all work in the master branch (perhaps with the occasional local topic branch) and so it’s sometimes been the case that the version of the code in the Git repo hasn’t been in a compilable state. As we’re currently working towards making a proper release of PolyVox, we decided that we should be more structured with our usage.

I’d heard good things about Vincent Driessen’s “successful Git branching model” and after reading it through we decided that it would be a good model to follow. Even better, he provides a cross-platform set of Git extensions called git-flow which make the whole process painless.

As of today, we will be using the new branching model. The master branch will now only contain released versions of the code and if you want to get the latest development version, you’ll have to check out the develop branch. When browsing the web interface at Gitorious, you’ll see that you can switch between branches by clicking the name in the grey box at the top or in the right-hand panel when browsing the source tree.

When it comes to release time, it’s simply a few commands to merge the develop branch into the master branch and tag the commit.

What this means for users is that we’ll be making more regular, stable releases and the git repository will be in a much more stable state for you to use.