Sollen mehrere Projekte mehrere TFS-Arbeitsbereiche haben?

Question

Wir haben vor 6 Monaten von VSS zu TFS migriert. Unsere Art, Projekte zu speichern, bestand darin, dass wir sie nach Kategorie gruppierten (Windows App, Web App, Infopath, SQLScripts, veraltet). Unter dem 'Windows App' Arbeitsbereich haben wir vielleicht 3 .NET Projekte. Die 'Web App' könnte 3, etc, usw. haben. VSS wurde mehr verwendet, um das Code-Repository zu speichern, als jede reale Funktionalität, die VSS bereitstellen könnte.

Windows-App ($/Windows-App/Arbeitsplatz)
-> App1
-> App2
-> Anw3

Web App ($/Web App/Arbeitsplatz)
- -> App1
-> App2
-> Anw3

Die Frage, die ich habe ist, wäre es besser, hat einen Arbeitsbereich für jedes Projekt? Einer der Gründe, warum ich für "Ja" halte, ist, dass wenn ich an mehreren Projekten in demselben Arbeitsbereich arbeite, wenn ich anhängige Änderungen einchecke, werde ich ALLE ausstehenden Änderungen anzeigen, einschließlich anderer Projekte, die ich momentan nicht arbeite in.

Web App/App1 ($/Web App/App1 Arbeitsplatz)
Web App/App2 ($/Web App/App2 Arbeitsplatz)
Web App/Anw3 ($/Web App/Anw3 Arbeitsplatz)

Ich denke, ich bin auf der Suche nach einer Best Practices-Antwort.

danke.

Answer 1

In dem Projekt, an dem ich arbeite, haben wir mehrere Zweige für verschiedene Versionen unserer Anwendung, und ich (persönlich) erstellen einen anderen Arbeitsbereich für jede Branche. Jeder Zweig ist ein "Projekt" für sich.

Es ist schön, weil es zu diesem Arbeitsbereich Ihre ausstehenden Änderungen lokalisiert - so 1 meine ausstehenden Änderungen für Zweig do up nicht zeigen, wenn ich auf dem Zweig gerade arbeitete 2.

Edit: ich habe gerade gelesen letzter Teil Ihrer Antwort - ja, ausstehende Änderungen für jeden Arbeitsbereich sind ein wirklich nettes Feature, und ich würde es als eine bewährte Methode ansehen, die Dinge so zu machen.