Team Foundation Server Source Control Structure

Question

I like your idea of putting the Sandcastle files as a peer to Source and Tests, I would add a documentation folder, that would then contain the sandcastle files, and optionally the actual documentation.

There are definetly differences of opinions and I'm sure I will be downvoted for this (since I have been before). I would put the generated documentation in TFS for a couple of reasons:

1. Your going to want your documentation with each release, and using TFS is an easy aproach to ensure your documentation stays in the correct place.
2. Using TFS to store it means everyone will know where to go get the documentation.

One thing I don't see which I always struggle with is where to third party dependancies, it might be that they belong down under the source so they are with each project although if you wanted to share them accross projects you could add a new top level node.

Edit

For my binaries I usually end up with

$/ThirdParty/Company/Product/Version/Src(optional)

So for example I have

$/ThirdParty/ Microsoft/ EntLib/ 3.1 4.0 ComponentArt/ WebUI/ 2008.1/ Src

I like to add the source, I've had to patch CA's source which I hate to do but when a third party doesn't fix the bug you have to resort to this.

Great layout and explanation. I've struggled with the exact same issues. I've wound up with a very similar structure. Mine varies slightly.

Development/
   Trunk/
      Binaries/  -- Shared libraries
      Source/
      Test/
      Docs/      -- Documentation
TeamBuildTypes/  -- Build definitions

• Adding the binaries folder allows you to have one location in the branch where all your projects can reference shared libraries
• We put the documentation here so it can travel along with it's specific branch.
• Our build definitions are at the development level since we can figure them in one location for all of the branches, but it could definitely be at the branch level which may make more sense.

Should binaries (controls, libraries, etc.) be stored in source control? If so, should it be it's own Team Project?

I think they should definitely be source controlled, but I don't see any reason to put them in their own team project. One issue to be careful with is TFS for some reason treats binary files slightly different. I've had issues where I've updated the binaries in source control, but "Getting Latest" on other machines doesn't cause update of the files. Sometimes you need to do "Get Specific Version" and check the "Overwrite Unchanged Files" option for that particular file.

You should put your TeamBuilds folder under your trunk. This was impossible in TFS2005 but Microsoft fixed it for 2008...

The reason for this is that your build may change with newer version (for example: new packaging schemes, different testing etc.) which may make it incompatible with older maintenance releases. Thats why you should couple the team build with the code's version.

This way, lets say you release a 1.0 version and put it under the Releases folder. You'll be able to build it and issue patches while working on v2.0 in your Development trunk (which may require modifying the build)

For your binaries - obviously the only binaries that should be under version control are "third-party" assemblies that you aren't "building" as part of any automated build. If you have your own libraries that you have their source under version control etc - you should look at various strategies for building and synchronizing etc.

I then organize them like Josh - and then use branching to "copy" the binaries to an _ExternalReferences folder which is a peer to the .NET Project folders within the solution tree. This is a very efficient way server side as TFS Version control only stores "Deltas" - so essentially every "duplication" of those binaries across many projects is essentially like a "pointer".

One thing I'd recommend is to not use the default location for team builds and include it in the 'branchable' level because as you branch for various reasons (say code promotions) you'll want your build scripts to be branched and synced with it.

Also a new and more scenario specific guide was just published as well at http://www.codeplex.com/TFSBranchingGuideII