We have projects that are umbrella projects for other “related” projects, which are loosely coupled and usually share no common codebase.
Our current logical structure in version control usually looks as follows. Each sub-product or initiative is represented as a separate feature, which came about as we were experimenting with folder structures and fighting with the TFSBranchTool which tried to enforce the defined feature branching scenario.
When we have to branch, we (at least I) get a twitch in one of the strained eyeballs … the oh, oh moment.
The resultant structure does not feel right, because the branch relationship are not reflected in the folder relationship in any way. When looking for a specific branch or getting to the reverse integrate (merge) the world does not feel intuitive. It turns into one of the “what was I thinking” moments.
Without getting embroiled in a debate whether our feature == product, I decided to restructure the logical structure of these types of projects as follows:
Iff (if and only if) the feature does not share the codebase the branching hierarchy (main|dev|rel) is moved within the feature node and the umbrella becomes an umbrella of products, each of which contain their own codebase and branching strategy. Also I no longer have to fight with the TFSBranchTool tool as it can create the selected branching scenario within the product/feature folder.
What do you think?