TFS Structure – Multiple Projects or Single Project?

Our small development shop is looking to migrate our projects from VSS to TFS, and we’re evaluating TFS vs. others (haven’t pulled the trigger quite yet). The nature of our software shop is such that we have 100+ projects in VSS ranging from small one-man-show projects to massive enterprise-wide applications.

We are trying to determine how to structure our projects in the transition and have, for the most part, decided on putting everything into one project site/system with each project having a subfolder off the root.

  • Error TF30170: “The process template you are using does not support Git.” when creating a team project
  • Team Foundation Server Source Control Structure
  • With this type of setup, we are concerned that we will lose a lot of the functionality that TFS provides (bug tracking, scrum burndowns, reporting, document storage etc.) because all the projects will be in the same portal/project space and it will be difficult to separate out individual project tickets/items.

    Does anyone have experience with this? What was your solution? Did you stick with TFS?

  • Why git and mercurial dont use database?
  • parent/child project relationship in Mercurial
  • Moving the .git directory wihout moving the files
  • How to create branch-specific files on GitHub
  • How do I safely disable/remove the largefiles directory from a mercurial repository?
  • git push showing “Everything up-to-date” but compare shows differences
  • 7 Solutions collect form web for “TFS Structure – Multiple Projects or Single Project?”

    The answer to this question requires some planning on your part: how you intend to use TFS, and which of those capabilities has inherent limitations in the product. I would summarize my advice as:

    1. You will need [at least] 1 team project per process template. That is, if two teams want to adopt / customize different processes, they will need to be separated.

    2. Once condition #1 is satisfied, you probably don’t need as many separate Team Projects as you think. 90% of TFS features & settings are hierarchical in nature, allowing you to scope them as broadly or narrowly as each of your projects requires.

    For complete details, see:

    The approach I’ve taken was to have a TFS project for each logical grouping of assemblies — So we’ve a framework project that contains assemblies common to all our applicaitons, we then have a separate project for our quotations system, another for the costing system and so forth. Whilst the workspace mappings get a bit “interesting”, it does allow different design methodologies for different projects, and at different timescales — so one team might be half way through a sprint (Most projects use Scrum for Team System), at the same time as another is just starting…

    It is true that to garner all of the benefits of TFS, it is best to use separate projects, but those benefits should be weighed against the administrative overhead associated with managing many projects. Years ago, I used Visual Source Safe…After I left Microsoft, I switched to Subversion. After returning to Microsoft, I am using TFS and so far I am very happy with it.

    The process guidance, the reports, the integrated bugtracking, and the tight IDE integration serve my needs perfectly. Plus, the TFS SDK allows for some interesting extensibiilty scenarios.

    I’ve used several SCC providers and we’ve settled on TFS for all of the features it has that others don’t. Bug correlation, CI and automated testing certainly topped the list of benefits.

    As for whether you use multiple project or not, I’d say it depends on if the projects share any common code. We tend to use a TFS project for all “related” code assets, so if we have several different solutions that do similar things and share a lot of code, we use a single TFS project. If they have nothing in common, then they become separate projects.

    I am not sure if this was fixed in 2008 but in 2005 when you built a project that was a subfolder of a root project, MSBuild will pull the entire source tree of the root project – even files that are not part of your subfolder.

    Depending on how much source you are managing this can greatly increase your build times.

    I realize this article is old, but TFS 2010 now supports a wonderful feature call Team Project Collections which is simply another level of indirection or grouping on top of Projects.

    This makes it much easier to create Team Projects without clogging up your namespace and encourages better organization!

    Great Link talking more about Collections

    I a not a sharepoint user but I hear its very similar concept to Sharepoint collections 🙂

    I prefer not to have my IDE try to be smarter than I am. I prefer to keep the code writing, the defect tracking, the project management and the version control separate. Perhaps I am still leery from SSafe…

    Try subversion. As for TFS it is really a tradeoff as to how you want to work.

    Git Baby is a git and github fan, let's start git clone.