Martin Woodward has made an interesting post about folder structure in Team Foundation Version control. I recognise the pattern that Martin advocates as being one that I have used with Subversion. What Martin is trying to do with his structure is support a very rich approach to branching and releasing of code, but I wonder if you can’t achieve the same result without any effort.
Major product releases should be tied to sperate team project. For example, version one of Onyx would be in a seperate team project to version two, and they would therefore have seperate areas allocated in version control (in fact the branch capability you get during team project creation supports this approach).
What I then like to see is within the version control area is the first piece of code that is checked in using a dirt simple name – like Onyx. This represents the main branch within the code base, then from that I would allow arbitrary branches, for example, someone might want to run on their own branch for a while because some of the changes they are making could destabilise everyone else – so they might create a branch called “Onyx-CrazyBob”.
Obviously naming is important, so for release drives I would do something like “Onyx-Beta1” and “Onyx-MarchCtp” and eventually stabilising and releasing off the trunk. At which point the next product cycle would kick in (or it may have already) and you take a branch as part of a new team project creation.
Anyway – its interesting to see what the different approaches are – I wonder if there is one correct approach?
Mitch, any thoughts on how to handle this slightly different branching situation? We have version 3.6 of the product, which 2 (out of 6) people are working on. And we have v4.0, which the other 4 are working on.
Everything in 3.6 needs to go into 4.0, but we dont want any of the changes in 4.0 going into 3.6.
Thoughts? Just cut a 3.6 branch off the main one now and merge often back into 4.0? Have you had to do this before?
If it helps, we are using Vault
Cheers
Nic
Hi Nic,
I wrote a couple of posts on my blog about different approaches to branching, one of which covers your scenario - but here is all of them.
http://notgartner.com/posts/3556.aspx
http://notgartner.com/posts/3549.aspx
http://notgartner.com/posts/3571.aspx
http://notgartner.com/posts/3577.aspx
http://notgartner.com/posts/3627.aspx
In your specific scenario though, I would branch from the trunk that is carrying your 3.6 code and work on the 4.0 version, then forward integrate from 3.6 to 4.0.
Mind you it may be too late for you to do that now, so you may want to treat 3.6 as an interim release branch off 4.0 and reverse integrate onto the 4.0 branch. Then in the future do a trunk per version that is going to RTM.
I doubt that there is one “correct” way of doing things - like everything in the IT world there are many answers with lots of shades of grey in between.
Different branching models work for different people - but I haven’t really seen an impartital discussion on branching modles and their pro’s and con’s. Possibly a subject of another blog post…
One of the things that is really exciting me is that proper branching is entering the real world (with Subversion, Vault and TFS all having extreamly powerful and flexible branching support).
Having said all this - a lot of people will never need to branch. Many in-house IT projects can live off the mainline dev branch and use CI techniques to reduce code integration problems.
With Microsoft bringing us branching in TFS it is about to get more mainstream adoption - it may well get over used for a while, but it adds one more arrow into the quiver of the IT guy which is a good thing.
I would be interested to hear more about your approach (with a picture if possible?). The experiemental branches you talk about usually go into the branch folder the way I work and we reserve a special folder called “releases” for code that we are going to have to seperately issue patches for as we continue to develop against the main line.
Cheers,
M.