I don’t deny it, my old tower PC at home has seen better days. It’s a Core2Duo system from 2007 and has served its duties. Thus, I’m looking for a replacement for this system for at most 800€, which will be able to serve at least for the next five years.

This is supposed to be a trilogy of articles. In this first one I’ll describe my current about-to-retire system, the requirements for the new and reasons for choosing the specific new components I’m about to order.
The second part will cover the building of the new system while the third and last part will give a resume of the new system including a few benchmarks as far as I’ll be able to conduct them.

Having a working test suite for your library or program is common knowledge. Using a continuous integration workflow like git-flow backed by Travis CI or a Jenkins instance is already a success story and widely used. To ease up the build process of a C++ library/program on different platforms, many projects decide to use CMake.

So far, so good. But how good is your test suite? Does it cover all the functionality and code in your library? Does it catch all the different branches and edge-cases?

This little article describes a way of using lcov to generate a test coverage report for a CMake-based C++ project.

The popular and state-of-the-art distributed version control systems (DVCS) tools Git and Mercurial are very likely the best way of reliably organising software development. Both have numerous advantages over their predecessor Subversion (SVN).

All three have a feature for handling nested repositories, which can but must not depend on each other: Git Submodules, Mercurial Subrepositories and Subversion Externals.

In this article I will describe an attempt of converting an existing SVN repository into a hierarchy of nested Git, Mercurial or SVN repositories while satisfying special demands on the whole setup.

If you are just interested in the final solution, scroll down to the conclusion. But be warned …

Dies soll eine kleine Anleitung sein, wie man die aktuellste (und stabile) Boost Version unabhängig von den Distributionspaketen installiert. Zum Zeitpunkt dieses Artikels war das Boost 1.52.0. Installiert auf einem 64bit openSUSE 12.2 (funktioniert ebenso mit 12.1).