Reczne tworzenie hierarchii branchów w TFS 2010

No tak… od jakiegoś tygodnia jedziemy produkcyjnie na TFS 2010 Beta 2. Zostaliśmy do tego trochę zmuszeni problemem z dotychczasowym TFS 2008 po marnej migracji domen(to grubszy temat, w każdym razie większość zespołu przestała np. widzieć swoje Work Itemy, a żeby komuś dać prawo korzystania z Source Controla, musiałem rzeźbić w bazie danych TFSowej. Polecam taką rozrywkę 😉 )., więc stwierdziłem, że warto spróbować już z dyszką, skoro MS jakośtam zachęca i sam korzysta w dogfoodzie ;).

Postawienie TFS 2010 nie polegało jednak u nas na wykorzystaniu opcji Upgrade, bo jak napisałem – z obecnym 2008 mamy problem, więc nie chciałem tego problemu przenieść do nowszej wersji. Straciliśmy wprawdzie ciągłość historii w Source Controlu, ale w razie czego stary server jest nadal aktywny(i na pewno nie pozbędziemy się za szybko przynajmniej baz danych z niego). Dodatkowo, żeby oczywiście było przyjemniej: zero Work Itemów, customizacje, i inne sprawy które wprowadziliśmy poszły sobie biegać, ale mimo wszystko woleliśmy mieć środowisko, w którym da się normalnie pracować.

Ale do rzeczy

Jednym z wyzwań, przed którym stanęliśmy, było odtworzenie hierarchii branchów – pewnie dałoby się jakoś mergować innymi narzędziami, ale zdecydowanie lepiej mieć odpowiednio odtworzoną hierarchię i tylko wybrać do którego brancha chcemy wmergować innego.
Jak zobaczyłem opcję „Convert to branch”, to zrobiło mi się nieźle 😉 Ale jak zobaczyłem okienko dialogowe pozwalające na konwersję, to generalnie cały entuzjazm poszedł w p… ole 🙂 Generalnie, z tego co zdążyłem wyczytać, nowy TFS inaczej traktuje(i wyraźnie rozróżnia) foldery i branche – np. stworzenie brancha z folderu spowoduje jego automatyczną konwersję również na brancha.

Więc nie miałem możliwości z poziomu GUI wskazania, że TEEEEN branch został utworzony z TEEEEGO i od tej chwili żyją długo i szczęśliwie. A skoro tak, to „welcome to SQL Management Studio” 😉
Poniżej wypisałem listę rzeczy, które trzeba zrobić/zmienić/obadać albo do których wypada z grzeczności zajrzeć, żeby banglało(uwaga – jest to tutorial mojego autorstwa i ponieważ sam skończyłem walki 2 dni temu, nie mogę wziąć odpowiedzialności za skutki uboczne, chociaż sam ich nie doświadczyłem):

1.) Najpierw w interfejsie konwertujemy ręcznie katalogi nadrzędny i podrzędny na branche(nic wielkiego tam się nie uzupełnia poza właścicielem brancha, ale jest to pole tylko i wyłącznie informacyjne)

2.) W bazie zaczynamy od tabelki tbl_Branch – znajdujemy na liście najpierw parenta, spisujemy sobie jego BranchItemId i konwertujemy, najlepiej mega tajnym narzędziem systemowym calc, na zapis HEX.
3.) Następnie dla rekordu reprezentującego brancha, którego chcemy dopiąć puszczamy update, wpisując w kolumnę BranchParent szesnastkowy zapis z pkt1.
4.) W tabeli tbl_MergeHistory umieścimy dwa rekordy:

insert into tbl_MergeHistory values (@branchId, 18, 18, @parentBranchId, 17, 17, 0,0,0,0)

insert into tbl_MergeHistory values (@parentBranchId, 17, 17, @branchId, 18, 18, 0,0,1,0)

Wartości 17 i 18 są przykładowe(prawdopodobnie to numery changesetów). Nie wiem jakie znaczenie ma wstawienie tam randomowo-kosmosowych wartości, lepiej chyba żeby się parami zgadzały 😉

5.) W tabeli tbl_Version zmieniamy Command na wartość 68(trochę magic number, nie potrafię powiedzieć dlaczego akurat 68 😉 domyślny wpis to 5).
6.) Trzymamy kciuki, żeby w Visual Studio w okienku „Merge…” w liście pojawił się odpowiedni branch, z którym będziemy się mogli zmergować 🙂

No Comments

Post a Comment

Time limit is exhausted. Please reload CAPTCHA.