how to manage a release of both sw and config data

Question

in my repository I've got a sw and a cfg(config) folder under trunk, I'm thinking that when I release I'll branch both of these to the releases folder e.g. v1 of my app, with London config data. If I want to release v1 of my app to NewYork too then I'm thinking I'll branch my config data off of main and adjust it in the release folder. Does this sound ok? have I missed something? I want to be able to tell 12 months from now which city has which version of the app, and be able to support their config data too. Cheers

Trunk
  sw
    qweqwe.cs, asdasd.cs etc.
  cfg
    setupData.inixmlwhatever

Releases
  London
    sw@v1
    cfg - London config data

  NewYork... app at v1, NewYork cfg
  Milan... app at v2, cfg data the same as London's but called milan.cfg
  Tokyo... app at v2 but with a Tokyo specific patch, with cfg data the same as Milan

of should I go:

Trunk
    sw
    cfg

Releases
    swV1
    swV2
    cfgTokyo
    cfgLondon
    cfgMilan

With this latter one, I don't know what version of the app's installed in London etc? I could use tags to get round this, but then someone might shift the tag. With the former, I've got loads of appV1's kicking about (which I'm ok with, branches are cheap etc. but it looks less organised).

Cheers

Answer 1

If at one point in time you have 3 cities, there exists 3 different config folders, each one in "production" and under maintenance. And when your product evolves, and you change something in the configs, you will have to adapt all three configs in parallel. Both of this means, you will need a working copy of each cities config in parallel. So you need them all in your trunk, not in different branches. This model will reflect this:

Trunk
    sw
    cfgTokyo
    cfgLondon
    cfgMilan

When creating release v1 now, you have

 Releases
     v1
        sw
        cfgTokyo
        cfgLondon
        cfgMilan

And you know exactly, that you have provided v1 for these 3 different cities (if the software is actually installed and used in production is a completely different question).

After that, you add New York, but only at v2. So your next release might look like this:

 Releases
     v2
        sw
        cfgTokyo
        cfgLondon
        cfgMilan
        cfgNewYork

Again, now you see exactly which city is assciated with version 2. If you need to add a new city to an older version (lets say, you want to add Berlin to v1), you can create a "maintenance branch" based on v1, add the "cfgBerlin" there and when you deploy it, you put it under Release/v1.1.

Do yourself a favor and don't make city-specific patches in different "sw" branches, only delivered to that certain city - put city specific things exclusively into your config files. If you need such a kind of patch, change your code below sw in your trunk in a way it checks some in the config to activate the specific behaviour - so "sw" wont't be branched, you still keep one main development line for all of your cities . Otherwise you will end in configuration management hell.

Answer 2

I highly recommend avoiding branches for this (As someone who has worked with both branch- and trunk-based development, the latter is very much to be preferred). You'll be copying commits forever between them, with very little possibility for an overview or a quick fix across the board when needed. Version control isn't configuration management; for that there's Puppet, Chef and a host of other solutions much better suited for just this kind of situation. And you should not rely on a source tree to know what's installed where - how do you know if version X for site Y has actually been deployed there? By inspecting what's on site Y, running my_software --version, cat /usr/local/share/my_software/version or something similar. If you don't even have read access there the deployment process should take care of updating some central service where you can find out what each site thinks it's got.