TFS 2010 Branch Across Team Projects-Best Practices

Question

TFS 2010 Branch Across Team Projects-Best Practices

Mam problemy ze zrozumieniem, jak skonfigurować TFS zgodnie z najlepszymi praktykami dostarczonymi przez TFS Ranger team. Problem jest taki:

Moja Firma ma kilka produktów, które wykorzystują wspólną bazę kodów.

> $/Core
>  -> /Main/Source (Parent Branch)
> 
> $/Product1
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...
> 
> $/Product2
>  -> /Main/Source
>  -> /Main/Source/Core/Source (Child Branch from $/Core)
>  -> /Main/Source/...

Dlatego mamy jedną kolekcję zespołów i powiedzmy, trzy projekty zespołowe dla tego przykładu. ($/*jest projektem zespołu)

Nasze początkowe rozgałęzienia uwalniania są trochę bolesne. Zamiast rozgałęziać się na / Main do / Releases, lub /Main do / Development, my zostały rozgałęziają każdy projekt indywidualnie. (nie team project ... projekt rozwiązania.) Wynika to z niemożności zagnieżdżenia korzeni gałęzi. (Zobacz błędy TFS: TF203028 i TF203071 )

Zgodnie z TFS Ranger Guide i naszym poprawionym podejściem do rozgałęziania wydań, poprawek, rozwoju, powinniśmy rozgałęziać się z /Main zamiast / Main/Source/Proj1,/Proj2, / Proj3, itp. To po prostu staje się dość dużą irytacją.

Idealnie byłoby like:

> $/Product1
> -> /Main/ (Branch - Parent)
> -> /Releases
>    -> /1.x
>       /1 Service Pack (Child Branch from $/Product1/Main
>       -> /1.0
>          -> /1.0 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.0 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>          -> /1.0.22 RTM (Child Branch from $/Product1/Releases/1.x/1.0/1.0 Hotfix - Read Only)
>       -> /1.5
>          -> /1.5 Hotfix (Child Branch from $/Product1/Releases/1.x/1 Service Pack)
>          -> /1.5 RTM (Child Branch from $/Product1/Releases/1.x/1.5/1.5 Hotfix - Read Only)

Rozwiązania: 1. Możemy przekonwertować każdą współdzieloną gałąź (np. $ / Core) z powrotem do zwykłych folderów. W ten sposób żaden folder pod /Main nie jest korzeniem gałęzi. Następnie możemy wykonać bezpodstawne Scalanie z $ / Product1/Main/Source/Core/Source z powrotem do rodzica $/Core / Source.

Czy ktoś ma jakieś doświadczenie z bezpodstawnymi połączeniami. To, co przeczytałem od Microsoftu, to to, że są wyjątkami, które nie powinny być powszechne. MS stwierdza, że jeśli poprawnie skonfigurujesz swoje projekty z TFS, nigdy potrzeba wykonania połączenia bezpodstawnego.

Jak to jest możliwe w przypadku rozgałęziania się między projektami zespołowymi?!? W każdym domu programistycznym powinno być powszechne posiadanie bibliotek współdzielonych między produktami.

Jestem otwarty na inne rozwiązania. Dzięki!

24

branching-and-merging tfs shared-libraries tfs2010

Author: Daniel, 2011-04-19

Source

4 answers

TFS 2010 Branching Revisited:

Chciałbym zaoferować tryb zaufania dla funkcji TFS 2010 baseless merge jako sposób na rozwiązanie tego problemu. Gorąco polecam lekturę książki "Professional Team Foundation Server 2010".

W nim opisuje ten problem dogłębnie i chociaż nie opowiada się za używaniem bezpodstawnych połączeń, rzuca światło na to, jak ich używać w scenariuszach takich jak ten.

Używamy ich odkąd to pytanie było pierwsze rozwiązane w kwietniu i jeszcze nie spotkały się z sytuacją, w której bezpodstawne połączenie stanowi problem. Chciałem zamieścić obrazek opisujący naszą konfigurację rozgałęzień zgodnie z zaleceniami książki i zespołu ALM Ranger.

Tutaj wpisz opis obrazka

6

Author: Daniel,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-06-22 18:45:18

Aby osiągnąć to, co chcesz, musisz najpierw przekonwertować wszystkie gałęzie pod root na folder, a następnie będziesz mógł przekonwertować root na folder.

Utknęliśmy przy scalaniu pod inną gałęzią, a potem przeszliśmy na scalanie bezpodstawne. Zajęło to trochę czasu, aby dowiedzieć się, jak to działa, ale potem udało nam się zrobić merge accross branch, a następnie stworzyć relacje między nimi.

tf merge /baseless "D:\TFS2010\Root\ServicePack" "D:\TFS2010\Root\MainLine" /recursive

Gdy wykonasz bezpodstawne scalanie, musisz sprawdzić wszystkie pliki. Nadal okaże się, że związek między gałęziami nie jest tworzony.

W tym celu kliknij gałąź ServicePack (jak na moim przykładzie), a następnie z menu Plik kliknij kontrolkę Źródła - > rozgałęzianie i scalanie - > Reparent. Tam będziesz miał możliwość ponownego rodzicielstwa. Gdy to zrobisz, zawsze, gdy chcesz połączyć te gałęzie, będziesz mógł to zrobić jak normalne scalanie między gałęziami. Tutaj wpisz opis obrazka

2

Author: Sunil Agarwal,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-04-22 11:16:39

Właśnie konfigurowałem TFS i spotkałem się z tym samym problemem. Chodzi o to, że nie ma potrzeby bezpodstawnego łączenia. Obejście:

Utwórz gałąź nadrzędną

$ / Core / Main
Utwórz gałąź potomną

$ / Product1
- >/Main
- >/Main / Core
- >/Main/...
Delete folder gałęzi potomnych

$ / Product1/Main / Core
Utwórz folder z ta sama nazwa

$ / Product1/Main / Core
Konwertuj folder Product1 do gałęzi

$ / Product1 / Main

Teraz możesz scalić zmiany z $/Core/Main do $/Product1/Main/Core i Wstecz.
Wizualizacja nie będzie działać dla gałęzi Core, ale chyba jest w porządku;)

1

Author: stbear,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-12-26 17:48:31

score 11 · Accepted Answer

Dorzucę opcję do ringu, może Ci się przydać. Jeśli to jakieś pocieszenie, zastanawiałem się nad tym od jakiegoś czasu i nie byłem w stanie wymyślić całkowicie satysfakcjonującego rozwiązania. To naprawdę dobre pytanie i byłbym bardzo zainteresowany tym, jak inni rozwiązali ten problem.

Wiem, że dobrym pomysłem jest budowanie ze źródeł, gdzie to możliwe, ale nie jestem fanem rozgałęzień między projektami zespołowymi. Jeśli masz jakieś wspólny kod i musi być rozgałęziony między 2 lub 3 innymi projektami zespołowymi, a następnie rozgałęzienie jest zarządzalne, ale jeśli masz 20 lub 30 (lub 100) projektów zespołowych, a następnie zarządzanie połączeniami staje się bólem głowy. Mogą wystąpić inne problemy, jeśli programiści pracujący w projektach zespołowych nie mają takich samych uprawnień w "master" , np. nie mogą zobaczyć historii itp. Oczywiście, jeśli masz kod, który musi być współdzielony między projektami zespołowymi w różnych kolekcjach projektów, to nie możesz branch w każdym razie.

Więc mając to na uwadze, sugerowałbym, abyś traktował wspólny kod w taki sam sposób, w jaki możesz traktować bibliotekę stron trzecich i używać binarnych odniesień. Po uzyskaniu tego sposobu myślenia dostępnych jest wiele opcji. (jest ich kilka, ale prawdopodobnie jest ich więcej)

możesz mieć kompilację wspólnego kodu skopiuj pliki binarne do miejsca zrzutu, wraz z modułem scalania do pakowania (jeśli używasz MSI). Następnie tworzysz binarne odniesienie do kropli lokalizacja i uzyskaj to, czego używasz do pakowania w celu zaimportowania modułu scalania. W tym scenariuszu musisz upewnić się, że lokalizacja zrzutu jest stabilna (i najlepiej tylko do odczytu dla większości programistów, aby zapobiec manipulacji)
podobnie jak opcja 1, ale użyj narzędzia takiego jak NuGet do zarządzania referencjami, zautomatyzuje to proces odwoływania się do nowych wersji plików binarnych. Może to nie być opcja, jeśli chcesz mieć większą kontrolę nad wprowadzaniem nowych wersji.
Ty można po prostu sprawdzić w binariach do $ / Product1 / branch / lib / common folderu w swojej gałęzi i odwołać się do nich za pomocą względnej ścieżki

Jak już powiedziałem, jestem bardzo zainteresowany tym, jak inni Soer rozwiązali problem współdzielonego kodu używając TFS.