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?