Tag Archives: Git

New home for PolyVox git repo

Posted on by
Reply

The source code for PolyVox is now located at BitBucket rather than its previous home on Gitorious. There are a few reasons we wanted to move hosting provider. Primarily we wanted an easier way of keeping track of planned features without messy email threads between David and myself and better bug tracking than our current forum-based method.

BitBucket offered everything we needed and since we were already using it for its unlimited private repos, it made sense to move PolyVox there too.

While we will be using the issue tracker to keep track of features and bugs, we will keep using the forum for most discussions. Feel free so submit any simple/small bugs to the tracker directly e.g. for compile errors etc.

To switch your local clone to follow the new repo on the command line just do the following:

# First check where you're currently pointing
$ git remote -v
origin  git://gitorious.org/polyvox/polyvox.git (fetch)

# Change the 'origin' remote's URL
$ git remote set-url origin https://bitbucket.org/volumesoffun/polyvox.git

# Now, it should look like
$ git remote -v
origin  https://bitbucket.org/volumesoffun/polyvox.git (fetch)

Otherwise, you can just use your GUI tool to change the repo URL to be https://bitbucket.org/volumesoffun/polyvox.git. You should now be able to carry on doing git pull as if nothing had changed.

Share

Some PolyVox Updates – Git and CMake

Posted on by
3

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.

Share