Visual Studio Team Foundation Source Control Best Practices

I recieved some email: 


Subject: Visual Studio Team Foundation Source Control Best Practices


Hi Charles,



We’re in the process of migrating from sourcesafe to Team Foundation Source Control and I have some questions regarding branching and merging for feature development and releases.


Specifically, when a branch is created in TFSC, it appears that the branch has to be tied to a physical directory on the local machine, as the rest of the project is. It does not appear possible to create a branch, then check it out over the top of the working copy of the trunk in order to build the branch from the same location as the trunk. The reason I want to do this is that, due to the fact that TFSC does not provide for source sharing, we have a separate team project, called that contains all our shared code. All our team projects are checked out to the same ‘root working directory’ and the team projects share files by adding existing files as links into the solution. See for a brief description on this method of file sharing between projects. Is it possible to map different branches within a project to the same physical working directory and specify which branch you are currently working on (and therefore which branch to check in to) ?


Could you point me to any sites that outline Microsofts recommended practices on branching, merging and releasing. Our branches are generally ‘short lived’ in that they are not used to keep two versions of a product in parallel development. Our branches are used more to insulate a line of development (eg for a feature implementation) from other changes that are being made to a project. Once the feature or features have been completed, the branch is merged back to the trunk and, generally speaking, will no longer be used. From the documentation I have been reading, it appears that this is not how the development team at Microsoft thought branches should be used.


Any information or guidance you can provide would be most appreciated.





Unfortunately not only can you not map multiple projects to the same local workspace; I don’t believe you can even map workspaces to children directories (at least you couldn’t in Beta2).   As far as best practices I am copying the author of the only Microsoft article I believe exists on the topic: Chris Birmele

As Chris points out his article is not a generalized best practice; which would be very dependent on the development process being used.  For instance the TFS team aggressively used Shelve sets and subsequent merging in their quasi waterfall SDLC-is this  a best practice?  Probably not for a true a XP shop as the shelve sets were being used for code reviews which wouldn’t be needed with true paired programming.


Other resources (Guidance) on the topic can be found at Mitchs blog: <no link provided>

Comments (0)