Question

In order to reduce repetition and streamline testing/debugging, I’m trying to find the best way to develop a group of libraries that many projects can utilize. I’d like to keep individual executable relatively small, and have shared libraries for math, database, collections, graphics, etc. that were previously scattered among several projects and in many cases duplicated (bad!). This library is to be in an SVN repo and several programmers will be working on it. This library will be in constant development along with the executables that utilize it.

For example, I want a code file in ProjectA to look something like the following:

using MyCompany.Math.2D; //static 2D math methods
using MyCompany.Math.3D; //static #D math methods
using MyCompany.Comms.SQL; //static methods for doing simple SQLDB I/O
using MyCompany.Graphics.BitmapOperations; //static methods that play with bitmaps

So in my ProjectA solution file in VisualStudio, in order to develop/debug the MyCompany library I have to add several projects (Math, Comms, Graphics). Things get pretty cluttered and Solution files get out of date quickly between programmer SVN commits.

I’m just looking for a high level approach to maintaining a large, shared code base in an SCN repository. I am fully willing to radically redesign my approach. I’m looking for that warm fuzzy feeling you get when you’re design approach is spot on and development is fluid and natural.

And ideas? Thanks!!

Answer 1

I would normally make use of SVN externals for this.

ProjectA
ProjectA\Libs
ProjectA\Libs\Maths     <-- svn:external pointing to your Maths repo
ProjectA\Libs\Comms     <-- svn:external pointing to your Comms repo
ProjectA\Libs\Graphics  <-- svn:external pointing to your Graphics repo

You may want to put all your libs in one repo – it depends on how big the code base is, how many different people are working on them, etc.

Then your build script is set up to build each of the libs projects before building ProjectA. This way you get the latest committed version of each library. If you wish to lock down the libraries to a specific revision, e.g., because you are tagging a release and you want to always get the same revision of libraries when you check out an older revision of ProjectA, you can specify a revision number in the svn:external URL.

Of course when using a lot of dependencies like this, you should have solid unit tests for all of your libs, and make sure they are run whenever you build.