Today while reading MSDN newsgroup I came across interesting piece of information that I was not aware of before. It turns out that Team Foundation Server supports maximum of 500 (five hundred) Team projects (as stated in official documenation); though in the newsgroup thread it is stated that the limit is not a hard one, it is still an official number.
While 500 is quite sensible number, I do find it rather disturbing; while not many organizations will have more than 10 millions of versioned items per project (10 millions as limitations go is not a very restrictive one), I can visualize organization having 500 logically separate software products or modules.
As Microsoft prefers working with a few projects (separating modules by using source control structure and area paths) it appears that having great many projects is rather gray area as of now. I would definitely say that the limit is one to be aware of in planning, though hardly a critical limitation.
Sunday, August 06, 2006
Maximum number of Team projects
5 comments:
Actually a TFS server will slow down significantly when you have around 150 projects.
Definatly a limit to watch and as you say prefer areas to always starting a new project. Kind of counter intuitive as you probably want a project sharepoint portal but now you have to adjust all reports to filter on area :-(
That's an interesting comment - I always wondered why Micrsoft prefer a few projects with multiple areas to many projects.
If TFS slows down when there are many projects, that makes a perfect sense!
Microsoft's soft guidance to prefer fewer team projects runs up against the system's limitations with respect to source control path length exceeding 260 characters. With fewer team projects, more organizational structure will be reflected in the directory structures of each project (i.e. instead of $/team-project/main you will see $/team-project/specific/main). The confluence of the limitations hurts.
Performance is definitely the limiting factor, but I was also under the impression that workflow of selected methodology, if one, is also critical in limits because of the number of rules applied to each action in the system. Microsoft states different limits for Agile vs CMMI. See http://msdn.microsoft.com/en-us/library/aa974183(VS.80).aspx for more info.
@mkmcgregor,
In TFS 2008 SP1 there is further improvement if you have many projects (see Martin Woodward's post at http://www.woodwardweb.com/vsts/filtering_wit_c.html)
Post a Comment