Bardzo krótkie kazanko, będące poniekąd drugą w tym tygodniu autoreklamą tego samego autoproduktu.
O wielu systemach kontroli wersji można powiedzieć, że są lepsze od innych. Podając na to wiele róznych argumentów.
Poniższy cytat odpowiada na pytanie “Why TFS is Better than X?”
It’s NOT !!! End of story.
Źródło: http://whytfsisbetterthanx.com
TFS wygrywa jak dla mnie na razie z jednym systemem – Perforce (no może poza prędkością). Język (werbalny), jakiego używam podczas korzystania z tego wynalazku nie mieści się w żadnym słowniku wulgaryzmów.
Co do repozytorium, ich wad i zalet – miałem okazję pracować z ClearCasem – Git też oferuje pracę na widokach? Tzn możesz zdefiniować sobie inne branche (i oczywiście ich wersje) które widzisz? Możesz definiować wersję z danego brancha (de facto są to kolejne commity), możesz widzieć całego innego brancha lub tylko wybraną część (plik/folder) itp. Dla mnie jest to fajne, że mogę pracować ze zmianami kumpla, które jeszcze nie są w głównej gałęzi. Bez zbędnych mergów (mergy?) itp. Masz jego zmiany, ale nie w Twoim branchu :)
W gicie też to jest?
yaceq,
Z Perforce nie korzystałem, dlatego z podlinkowanej strony go usunąłem mimo że był w oryginale:).
ClearCase nie znam zupełnie, ale:
"[i]Git też oferuje pracę na widokach? Tzn możesz zdefiniować sobie inne branche (i oczywiście ich wersje) które widzisz?[/i]"
Jak najbardziej, możesz tworzyć gałęzie, tagować je, dowolnie się po commitach nawigować… Ale to chyba można wszędzie robić, tylko z różną skutecznością, więc nie wiem czy dobrze zrozumiałem pytanie.
"[i]Możesz definiować wersję z danego brancha (de facto są to kolejne commity), możesz widzieć całego innego brancha lub tylko wybraną część (plik/folder) itp[/i]"
Interpretuję to jako "partial checkout", czyli możliwość ściągnięcia (i pracowania na) tylko części repozyorium.
Tego mi dość mocno brakowało po przesiadce z SVN na Gita, ale koniec końców wyszło na dobre. Wcześniej miałem wszystkie swoje projekty w jednym repozytorium, więc w historii/logach był niezły śmietnik. Po przejściu na Git każdy projekt ma swoje repo i tak moim zdaniem powinno być.
ALE funkcjonalność ta została dodana ok półtora roku temu do Gita w wersji 1.7.0. Nazywa się sparse checkout… i z niej nie korzystałem:).
"[i]Dla mnie jest to fajne, że mogę pracować ze zmianami kumpla, które jeszcze nie są w głównej gałęzi. Bez zbędnych mergów (mergy?) itp. Masz jego zmiany, ale nie w Twoim branchu :)[/i]"
Jak najbardziej.
Chodziło mi bardziej o to, że możesz zdefiniować sobie w swojej konfiguracji jakie branche widzisz. Tzn masz swój widok (możesz mieć ich wiele ale tak na prawdę jeden widok to coś na kształt workspace’a) i w tzw config-specu czyli de facto konfiguracji widoku definiujesz brancha, na którym pracujesz (do którego zapisujesz pliki itp) ale obok niego definiujesz listę innych branchy które chcesz widzieć (widzieć = zmiany z tych branchy pojawią się fizycznie w Twoim lokalnym file-systemie). Znudził Ci się jakiś branch – wywalasz go z tego config-speca i voila. Nie musisz robić żadnych więcej czynności by dodawać kod kolegi i go usuwać. Żadnych mergy tylko zmiana konfiguracji i cudzy kod się pojawia lub znika odpowiednio.
Bardzo dobre rozwiązanie gdy mamy dwie osoby, odpowiednio jedną do pisania kodu a drugą do pisania testów. Tester wtedy do swojego widoku wrzuca brancha programisty, może napisać testy i oczywiście vice-versa, programista może pracować z testami testera. Gdy wszystko jest już gotowe dopiero wtedy zrobić jednego merga z tych dwóch gałęzi i wrzucić to roota.
Z gitem nie miałem jeszcze okazji pracować, ale myślę że jeszcze wszystko przede mną :)
yaceq,
Tak, jest taka funkcjonalność – "tracking branches". Konfiguruje się które gałęzie z którego zdalnego repo mają być śledzone -> tworzy się śledzące je lokalne branche. Co prawda "pull" ściąga wszystkie zmiany z całego repo, ale nie trzeba wykonywac żadnego łączenia aby zobaczyć cudzy kod. Sam tak zresztą pracowałem – "cssowiec" miał swój branch i tylko do niego pchał zmiany, ja byłem odpowiedzialny za zintegrowanie tego z "masterem" (wtedy kiedy mi pasuje, a nie wtedy kiedy zmiany się pojawią), czyli gałęzią która docelowo szła na produkcję.