Team Foundation Server Source Control Structure

Question

I have been working on standardizing the source control structure for our Team Foundation Server rollout for the new year. I have started by using the Microsoft Team Founda

Answer 1

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.