3

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

2 Answers 2

5

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.

3
  • thanks, for FAT and UAT 'testing' configs I'm thinking I use the cfg under trunk and put a tag on it? this feels a bit clumsy
    – timB33
    Sep 12, 2014 at 12:04
  • @timB33: honestly, I don't known what you mean by FAT and UAT. To avoid doubled efforts, it is import you keep the configs as small as possible (but not smaller) - make sure they contain only stuff you really need to configure for your "cities", not more (and not less, every configurable stuff should be there and not somewhere else).
    – Doc Brown
    Sep 12, 2014 at 13:26
  • Factory and User acceptance tests. We've got a massive config file detailing all kinds of assets (cameras, lasers etc.) for our testing the lasers are all set to stun etc. but in the field they're not etc. Hence why I've been thinking about tweaking and testing the config files in trunk and then branching to release where I set things to active. Thanks for your comments.
    – timB33
    Sep 12, 2014 at 14:45
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.

1
  • You're not the only person to suggest puppet and chef etc. and TBH I'd not even considered it. Short term I'll stick with my current setup but I'll revisit this later. Thanks
    – timB33
    Sep 12, 2014 at 14:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.