Czy wiele projektów ma wiele obszarów roboczych TFS?

Question

Przeprowadziliśmy migrację z VSS do TFS około 6 miesięcy temu. Naszym sposobem przechowywania projektów było pogrupowanie ich według kategorii (aplikacja Windows, aplikacja internetowa, program InfoMath, skrypty SQL, wycofane). W obszarze roboczym "Aplikacja systemu Windows" możemy mieć 3 projekty .NET. "Aplikacja internetowa" może mieć 3, itd. Itp. Usługa VSS została wykorzystana bardziej do przechowywania repozytorium kodu niż jakakolwiek rzeczywista funkcjonalność, którą może zapewnić usługa VSS.

systemu Windows App ($/Windows App/roboczy)
-> Apl1
-> Apl2
-> App3

Web App ($/Web App/roboczy)
- -> Apl1
-> Apl2
-> App3

mam pytanie jest, że byłoby lepiej mieć 1 miejsce pracy dla każdego projektu? Jednym z powodów, dla których myślę "tak", jest to, że jeśli pracuję nad wieloma projektami w tym samym obszarze roboczym, gdy wykonuję takie czynności, jak sprawdzenie oczekujących zmian, to pokaże mi WSZYSTKIE oczekujące zmiany, w tym inne projekty, w których obecnie nie pracuję. w.

Web App/app1 ($/Web App/Apl1 obszar roboczy)
Web App/App2 ($/Web App/Apl2 obszaru roboczego)
Web App/App3 ($/Web App/App3 roboczy)

Podejrzewam, że szukam odpowiedzi na pytanie o najlepsze praktyki.

dzięki.

Answer 1

Nad projektem, nad którym pracuję, mamy kilka oddziałów dla różnych wersji naszej aplikacji, a ja (osobiście) tworzę inny obszar roboczy dla każdej gałęzi. Każda gałąź jest sama w sobie "projektem".

To miłe, ponieważ lokalizuje oczekujące zmiany w tym obszarze roboczym - tak moje oczekujące zmiany na oddział 1 nie pojawi się, gdy pracuję na oddziale 2.

Edit: po prostu przeczytać ostatnia część odpowiedzi - tak, oczekujące zmiany w każdym obszarze roboczym to naprawdę fajna funkcja i uważam, że najlepszą praktyką jest robienie rzeczy w ten sposób.