Najlepsza praktyka łączenia plików rozwiązania z konfliktami id projektu

Question

Powiedzmy, że gałąź TFS została utworzona z jakiegoś głównego oddziału, który miał 2 projekty (FirstNewProject), ale podczas gdy praca wciąż trwała w tej gałęzi, utworzono inny oddział (SecondNewProject) zadanie zostało zakończone i ten drugi oddział został ponownie połączony.

Jeśli teraz spróbować połączyć to pierwszy oddział z powrotem do głównej gałęzi, z których oba te oddziały były rozgałęzionego teraz mamy konflikt w pliku rozwiązania, które mogą być ręcznie pozornie rozwiązany tylko ...

Pierwszy konflikt to zmienna TFS SccNumberOfProjects = 3, która jest taka sama w obu plikach rozwiązania FirstNewProject i SecondNewProject, ale musi zostać zmieniona na SccNumberOfProjects = 4, ponieważ po ponownym scaleniu SecondNewProject liczba projektów wynosiła 3, ale teraz, gdy łączymy FirstNewProject, liczba projekty są teraz 4.

Zmieniono ręcznie tę zmienną na 4, aby utworzyć nieprawidłową plik rozwiązania?

Drugi konflikt znajduje się w sekcji Global i ma związek z numeracją projektów.

SecondNewProject dodaje te linie do pliku Rozwiązanie:

SccProjectUniqueName3 = SecondNewProject\\SecondNewProject.csproj 
SccProjectName3 = SecondNewProject 
SccLocalPath3 = SecondNewProject 

FirstNewProject dodaje te linie do pliku Rozwiązanie:

SccProjectUniqueName3 = FirstNewProject\\FirstNewProject.csproj 
SccProjectName3 = FirstNewProject 
SccLocalPath3 = FirstNewProject 

Ale FirstNewProject jest teraz 4-cia projekt więc powinniśmy zmienić te wpisy do

SccProjectUniqueName4 = FirstNewProject\\FirstNewProject.csproj 
SccProjectName4 = FirstNewProject 
SccLocalPath4 = FirstNewProject 

ręcznie i spowoduje to, że plik rozwiązania będzie nieprawidłowy i czy jest jeszcze coś do zrobienia, gdy wrócisz do takiej sytuacji?

Answer 1

Zakładając swoją strukturę oddział jest jak:

FirstNewProject 
/
Main branch 
\ 
SecondNewProject 

Teraz masz edytowane zarówno FirstNewProject i SecondNewProject i scalić FirstNewProject do głównej gałęzi, a także SecondNewProject. SccNumberOfProjects w SecondNewProject to 3, a SccNumberOfProjects w FirstNewProject to 4, więc nie masz pewności, czy SccNumberOfProjects w gałęzi głównej ma być 3 lub 4, czyż nie?

Nie jestem pewien, dlaczego pytanie o zmianę SccNumberOfProjects spowodowałoby, że plik rozwiązania byłby nieprawidłowy. Ponieważ wykonujesz scalenie między gałęzią główną i innymi gałęziami, gałąź źródłowa i gałąź docelowa powinny być takie same.

Pod względem Oddziału i połączyć strategie, podstawowy plan oddział powinien wyglądać jak poniżej zrzut ekranu pokazuje:

główna gałąź jest gałęzią skrzyżowanie między rozwojem i zwolnić oddziały. Ta gałąź powinna reprezentować stabilną migawkę produktu, którą można udostępnić za pomocą kontroli jakości lub zespołów zewnętrznych. Zwolnij gałąź ma wyizolować kod w ramach przygotowań do wydania. A wszystkie zmiany powinny nastąpić w branży deweloperskiej. Gdy kod działa dobrze w gałęzi Rozwój, połącz go z gałęzią główną. Jeśli chcesz zwolnić rozwiązanie, połącz się z gałęzią główną do gałęzi wydania.

Dla swojego scenariusza, należy sprawdzić, który oddział chce i zmodyfikować oddział, aby rozwiązać konflikt.Następnie możesz postępować zgodnie ze strategią oddziału, aby zarządzać swoimi oddziałami.

Answer 2

Scalanie sln to straszne przeżycie. Jednak widzę inne rozwiązanie tego problemu - dlaczego nie zachować wersji lokalnej, a następnie ręcznie dodać nowy projekt (z wizualnego studio). Wiem, że jest to instrukcja ręczna, ale jest o wiele mniej podatna na błędy