Branching Strategy and Tracking ChangeSets to Multiple Branches
I am trying to work out the best branching strategy and whilst I realise team foundation pretty much allows for any scenario, this unfortunately makes deciding on a strategy even harder :)
As a minimum I want to have a multiple branches that represent a baseline of code on each of my testing environments (dev,testing,staging,production). Are there any basics rules to observe for example should these be represented as folders branched within the same TeamProject, or should I have a Team Project maybe that represents each of my environments?
Also, I have been experimenting within branch/merge. The main problem I have come up against is the fact that if I have a development team of say 20 working on a branch(1) for several days, weeks, months etc - I may want to eventually merge all those changesets into another branch(2). The problem is if I merge all those changesets into branch(2) in one operation, the checkin of that merge becomes a single changeset and therefore if I want to merge from branch(2) to a further branch(3), I lose the granularity being able to merge the original changesets - there is not even a link to say that the single changeset created when merging into branch(2) was as a result of all the changesets carried out in branch(1)
I hope that makes sense!!
Yes, I believe you should have them as different branches in the same Team Project.
Yes, I understand the loss in granularity in the merge process. It's a very hard problem to solve because you can merge partial change sets, etc. In addition the merge operation may include conflict resolution changes that weren't ever in any of the original change sets being merged over. In the future I hope we can do something to make the merge result a little less opaque. We're working on some visualization tools to make it easier to see what was merged over and when.
Brian
Yes, when you create a build, it creates a workspace specification that describes what files to sync in order to build your projects. By default this workspace specification contains all the files in your team project (even if you only pick a few solutions to build). You can edit your workspace specification (it's one of the xml file - I can't remember the name right now; I'm at home and not at work :)). Look in the folder that contains the build configuration info - it's reasonably straight forward to identify it. You need to trim down what is contained in the workspace to just contain the branch and then only those change sets will be included in the build info.
