Tak jak wspominałem w swoim rocznym podsumowaniu – wraz ze zmianą cyferek w kalendarzu znacznej zmianie uległa moja sytuacja zawodowa. Co za tym idzie – musiałem przeprosić się ze znienawidzonym TFSem. Właśnie minął mój pierwszy tydzień z tym narzędziem i postanowiłem zebrać swoje dotychczasowe wrażenia.
Kontekst
Nie jest to moje pierwsze TFSowe randewu. Wcześniej korzystałem z niego dwukrotnie – zawsze babrając się jako programista tylko w kontroli wersji, bez łorkajtemów, uzerstoris etc. Efektem była gruba, kolczasta, płonąca i ociekająca żerczym kwasem ściana nienawiści między nami. Przyrzekałem sobie że “nigdy więcej”, aż tu nagle… No ale, życie przynosi niespodzianki.
Z pewnym zaskoczeniem zauważam, że do tej pory prawie nie poruszałem tego tematu na blogu, znalazłem raptem jeden post z tagiem “tfs”. Wygląda na to, że czas to zmienić.
Od strony “meneżera”
Zakres moich obowiązków się zmienił. Teraz interesuje mnie nie tylko kontrola wersji, ale także zarządzanie zadaniami, obserwowanie postępu, monitorowanie pracy zespołu itd. Co prawda od lat jako freelancer musiałem ogarniać całościowo większość tworzonych przez siebie projektów, jednak nie była to “praca zespołowa” w pełnym znaczeniu tych słów. Teraz jest trochę inaczej i z tej perspektywy nigdy na TFS nie patrzyłem. Muszę niestety przyznać: spod nowego kąta wygląda całkiem imponująco.
Mam porównanie z wieloma systemami do zarządzania projektem (to temat na osobnego posta, do którego notatki zbieram od roku) i w większości z nich samo “zarządzanie pracą”, czyli wprowadzanie i edycja zadań, jest o wiele wygodniejsza. Ale za to możliwości raportowania w TFS zrobiły na mnie spore wrażenie. Wszystkie te statystyki ubrane w wykresy i diagramy wyglądają bardzo użytecznie – odpowiednio wykorzystane faktycznie mogą dać kontrolę nad projektem i w miarę szybkie zorientowanie się w aktualnym stanie prac. Z czymś tak zaawansowanym jeszcze się wcześniej nie spotkałem – to był najsłabszy punkt innych stosowanych przeze mnie rozwiązań.
No i to właściwie tyle z perspektywy team leadera: średnio wygodne definiowanie/przydzielanie/edycja zadań i bardzo imponujące raportowanie. I uwaga: to ostatnie działa niesamowicie wolno, ale nie wiem czy to kwestia konfiguracji środowiska czy samego TFSa.
Od strony programisty
Tutaj wchodzimy w obszar, który wcześniej tak mnie do TFSa zniechęcił. Minęło kilka lat… i nic się nie zmieniło. Pierwsze wrażenie: podpinam się z VS pod ProjectCollection i kwadrans spędzam gapiąc się na komunikat “Contacting server to get list of items to update“.
Chcę zobaczyć kiedy projekt został aktualizowany, więc spoglądam na kolumnę “last check-in” w roocie projektu: a tam jakaś data sprzed lat. Dopiero zagłębienie się w odpowiedni folder podało mi w tej kolumnie datę, której szukałem. Szczęka mi opadła i kilka włosów od razu posiwiało – przecież to jest tak głupie, że aż nie do wiary!
No ale dobra, mam w końcu projekt na dysku, lecimy dalej…
Wchodzę w jakiś katalog z poziomu Total Commandera (dość często edytuję pliki poza VS, bo tak bywa o wiele sprawniej – bądź też pliki nie są dołączone do .sln), otwieram coś w notepad2, modyfikuję, zapisuję… i zonk. Plik jest readonly. Odhaczam więc ten atrybut we właściwościach pliku, zapisuję bez problemu, chcę zmianę pchnąć do repozytorium… i zaskoczenie. Okienko “Pending changes” nie widzi tych zmian, bo nie edytowałem pliku z poziomu VS! Jak sobie z tym poradziłem? Skopiowałem nową zawartość do schowka, w panelu “Source control” odnalazłem ów plik, wymusiłem przywrócenie jego poprzedniego stanu przez kliknięcie “Get latest version” i zaznaczenie jakichś 2 dziwnych checkboxów wymuszających nadpisanie tego co mam na dysku zawartością z repo, otworzyłem plik w VS, wkleiłem zawartość ze schowka i wreszcie poszło do repo. Damn, mamy XXI wiek, w ten sposób to Ulrich von Jungingen mógł aktualizować status bitwy pod Grunwaldem!!
Wiele razy za to zdarzyło mi się zobaczyć w “Pending changes” pliki, w których nic się nie zmieniło. I VS wie że nic się nie zmieniło, bo jak klikam “compare with previous version” to mi pisze że “files are identical“. A mimo to pokazuje je w “pending changes“. Debil.
System kontroli wersji powinien bardzo pomagać podczas przeglądania historii projektu w kontekście pojedynczych commitów. I tutaj również TFS zawodzi. Pierwsze co rzuciło mi się w oczy to brak “bocznego paska” w narzędziu do porównywania plików, pokazującego zmiany w skali całego pliku a nie tylko treści widocznej na ekranie. Wychodzi na to, że muszę przewinąć cały plik aby znaleźć wszystkie zmiany w nim popełnione – nie da się jednym rzutem oka ocenić gdzie zmiany zostały wprowadzone. W każdym innym znanym mi diff-tool taki “podsumowujący” pasek istnieje i nie wyobrażam sobie code review bez niego. Mało tego: to TFSowe narzędzie nie wykrywa zmian na poziomie znaków, a na poziomie całych LINII! Bardzo głupio to wygląda po przyzwyczajeniu się do “luksusów” oferowanych przez alternatywne rozwiązania. Dodatkowo ciężko jest obejść się bez myszki podczas przeglądania commitów – nawigacja klawiaturą nie jest zbyt wygodna ani wystarczająca. Na przykład w menu kontekstowym wyświetlanym dla zmodyfikowanych plików nie ma “akceleratorów”, czyli literowych skrótów pozwalających na wykonanie konkretnej komendy. Heh, mało tego – w okienku podglądu zadań można zobaczyć co prawda listę podpiętych pod dany task checkinów (w zakładce “linked items“), ale… nie da się z tego poziomu sprawdzić ani kto jest autorem commita ani kiedy został on przysłany do systemu! Nie to że domyślnie nie wyświetla się taka informacja, ale z tego co wyczytałem: po prostu się NIE DA.
A gdy chciałem cofnąć zawartość pewnego pliku o 2 commity to musiałem wykonać po kolei: “get specific version” -> copy -> “get latest version” -> paste -> checkin. Mam szczerą nadzieję, że da się to zrobić jakoś mniej morońsko, feedback w komentarzach mile widziany.
Heh, i jeszcze jedno: niejednokrotnie zbaraniałem, gdy TFS napisał że nie weźmie mojego checking ponieważ nie spełnia on “checkin validation” – ale nie powiedział mi dlaczego tak jest. Jedyne co zobaczyłem to “One or more checked work items failed the transition testing due to invalid field values.” – i musiałem dopytywać w zespole o co chodzi, co może być nie tak.
Konkluzja
Wniosek jest bardzo prosty: dla osoby niekodującej, a tylko patrzącej na wykresy, TFS jest narzędziem naprawdę niezłym. Jednak wrzucanie w to bagno programistów tylko dlatego, żeby meneżer miał fajne statystyki, wydaje mi się nie do końca odpowiedzialne. Albo może nawet: niemoralne:). TFS narzuca na zespół tyle idiotycznych, bezsensownych ograniczeń, że aż wierzyć się nie chce! W końcu to już chyba trzecia wersja tego narzędzia, a ja nadal preferowałbym SVN (którego też od dawna nienawidzę)! Straszne jest też to, jak wiele osób świadomie akceptuje te ograniczenia, bo “w sumie to nic innego nie jest potrzebne“. Jednak każda z takich osób, z którymi miałem kontakt, nie pracowała nigdy z alternatywą.
Są naprawdę o wiele, o wieeele (!!!) lepsze narzędzia do zarządzania kodem. I, uwaga!, da się je w miarę bezboleśnie z TFSem zintegrować. Ja już jestem w “tfs-free comfort zone” – moja cierpliwość wyczerpała się po 3 dniach, w czasie których i tak prawie wcale z kodem nie pracowałem. Co poniektórzy pewnie już się domyślają o co chodzi, ale o tym wkrótce.
Ale póki co zawołanie do programistów zmuszanych do użerania się z TFSem: zaciskajcie, jak Czesiek, zęby, których nie macie i nie traćcie nadziei, zaraz za zakrętem czeka lepsze jutro;). Część problemów przedstawionych wyżej da się obejść – o tym także niedługo postaram się napisać.
W kwestii readonly – to zamiast odznaczać atrybut było trzeba zrobić "Check out for edit" – ja sie do tego przyzwyczaiłem (i podejrzewam że wiele osób które muszą tj. mogą korzystać z TFSa też). Podobno w TFS 11 zostało to już usprawinione. Póki co warto sobie zainstalować Power toolsy dla TFSa – wprowadzają one integracje z Shellem jak to jest w przypadku Tortoisa.
Jeśli chodzi o brak paska ze zmianami w porównywaniu wersji – też się to zmienia w następnej wersji TFSa (http://blogs.msdn.com/b/bharry/archive/2011/08/31/merge-enhancements-in-tfs-11.aspx) – a przy okazji dochodzi opcja "Request code review".
Generalnie polecam przejrzenie wpisów Briana dotyczących usprawnień w nowym TFSie.
slawek,
Power tools mam zainstalowane, m.in. o tym napiszę nastęnym razem. Ale rozwiązanie z "check out for edit" nie jest dla mnie akceptowalne – system kontroli wersji powinien sam wiedzieć co się zmieniło. Po co mam mu to mówić, skoro zna przecież stan "przed" i stan "po"? Dodatkowo: czy taka czynność nie wysyła na serwer – a co za tym idzie, do całego zespołu – informacji które pliki ja edytuję? Po co im to wiedzieć? (wiem po co – żeby tych plików nie ruszać bo potem wszystko wybuchnie przy merge;) )
Dzięki za linka, faktycznie w 11 wygląda to dużo lepiej.
Panie Macieju,
Z tego co widzę, niechęć do Microsoftowego TFS’a wynika w dużym stopniu z kłopotu ze zwalczeniem pewnych przyzwyczajeń…
"Edycja plików poza VS" – proszenie się o kłopoty na własne życzenie.
"Dopytywanie zespołu" – co w tym złego? Jest to jak najbardziej pożądana praktyka :).
Odnośnie długiego czasu oczekiwania na połączenie z repozytorium i pobranie źródeł, to (odbijając piłeczkę) – ja w pracy miałem identyczny problem z SVN’em, TFS działa w porównaniu z nim o wiele szybciej. Może w Waszym przypadku nie jest to kwestia platformy tylko ustawień sieci lub generalnie wydajności serwerów lub stacji roboczych ?
Oczywiście narzędzie nie jest idealne i pewnie brakuje mu kilku przydatnych opcji o któych wspominasz, ale cóż – na podstawie swoich kilkuletnich doświadczeń z tą platformą, zapewniam Cię, że daje się bez nich żyć :)
TFS podobnie jak każdy podobny tool narzuca pewnien model uporządkowanej pracy zespołowej (z naciskiem na ZESPOŁOWEJ, a niestety obecnie zespoły to nie tylko programiści), który możemy zaakceptować i wykorzystywać, albo… cóż męczyć się i rzucać gromami tak jak Ty to aktualnie czynisz :).
Pozdrawiam,
PG
Piotrek (lub "Panie Piotrze", ale to chyba zbyt oficjalne;) ),
System kontroli wersji nie powinien wpływać na to czy edytuję pliki w VS czy poza nim. Samo VS jest wolne i często o wiele wygodniej jest coś zrobić w ogóle go nie otwierając, tym bardziej jeśli nie chodzi o kod. TFSowi nic do tego – on ma tylko zarządzać zmianami w plikach, a nie narzucać jakiś konkretny sposób generowania tych zmian.
Co do wydajności – bynajmniej nie piszę, że SVN jest szybsze, bo jak wspomniałem od SVNa uwolniłem się już dawno temu, i nie tęskię.
Co do ograniczeń i tego że "da się z nimi żyć" – o tej postawie też pisałem. Oczywiście że się da, da się też pakować codziennie przed wyjściem pracy cały kod do zipa i wysyłać go na zdalny ftp celem backupu. Nie chodzi o to co się "da", tylko o to co najbardziej służy zespołowi/projektowi. Podejście że "coś nie jest idealne, ale zaakceptujmy i nie szukajmy lepszych rozwiązań" jest mi obce. Praca ma sprawiać przyjemność, a nie być ciągiem walk z narzędziami, które "trzeba zaakceptować".
Na koniec odniosę się do "TFS podobnie jak każdy podobny tool narzuca (…)". Nie każdy. Z TFSem jest taki właśnie problem, że zbyt wiele narzuca. I narzucane rozwiązania są bardzo często bez sensu. Podział na programista/nieprogramista zauważyłem, ale ja uważam że to programiści są najważniejsi w całym tym galimatiasie. I to oni najwięcej cierpią przy TFS, często nawet nie zdając sobie z tego sprawy.
No ale nie przeciągając – zapowiedziałem przedstawienie leku (przynajmniej częściowego) na to zło, gdzie i wilk syty (tzn meneżer ma swoje wykresy) i owca cała (programista może wygodnie pracować).
I jeszcze standardowe pytanie: czy pracowałeś z czymś innym? Nie SVN lub VSS, ale git hg czy bazaar? Jeśli nie to dyskusję tą znam na pamięć i nie ma sensu się w nią po raz kolejny zagłębiać.
Co do diff toola, to zgadzam się w pełni, że jest to bardzo słabe narzędzie. Zarówno do porównywania różnych wersji, jak i do robienia merge.
Ale w ustawieniach TFS Explorera jest możliwość wskazania zewnętrznego diff/merge toola. Ja sobie podpiąłem WinMerge – po tym zabiegu diff/merge był już dużo przyjemniejszy :)
Bartekw,
Ano o tym też będzie w poście o ułatwianiu sobie życia z TFSem:)
@Piotrek Gaszewski
‘"Edycja plików poza VS" – proszenie się o kłopoty na własne życzenie’ – to chyba nielekka przesada :) VS może i jest jedyny i słuszny, i nic innego nam (.NETowcom) nie potrzeba, lecz za oknem istnieje inny świat (http://wekeroad.com/2011/11/26/yes-the-forest-is-full-of-trees/) i jest on całkiem fajny ;) Czy jeżeli wiesz co chcesz zmienić i w jakim pliku to musisz odpalać wielką kobyłę żeby zrobić zmianę jednej linijki? Moim zdaniem nie – to VS jest dla nas a nie my dla niego.
Maciek,
Z powyższego wynika, że interesuje Cię głównie perspektywa programisty, z sprawnym VSS jako krytyczną cechą systemu do pracy zespołowej. Jeśli nie ma więcej wymagań to dlaczego TFS?
Używanie TFS tylko do VSS to strzelanie z bazooki do mrówek. TFS to nie tylko raporty i VSS.
Tam jest CI, automatyzacja testów, automatyzacja buildów, branching/merging i wiele wiele więcej fundamentalnych klocków, które zaczynają mieć wartość wtedy, gdy w sposób przemyślany z perspektywy zespołu (niezależnie jaki soft by to wspierał) są przemyślane i konsekwentnie wykorzystywane. Wtedy wspólnym mianownikiem do oceny powinien być zespól. Zespół, który fakt, performuje tak jak jego najsłabsze ogniwo, ale wciąż zespół.
W każdym innym przypadku może być właśnie taki komentarz jak opisujesz: nie wiem, nie działa, nie rozumiem, bez sensu…
A to taka subiektywna prawda, prawdziwa bo "MOJA" :)
h-one,
Kiedyś TFS interesował mnie tylko jako kontrola wersji, ale teraz już nie. Starałem się to podkreslić w tym poście. I tam gdzie spełnia swoje zadanie – oddałem mu to i napisałem cechy pozytywne, żeby nie było to bezmyślne wylewanie swoich żali. Naprawdę starałem się być obiektywny, cokolwiek to będzie znaczyło.
Każdy z elementów TFS który opisałeś można zastąpić lepszą alternatywą i efekt tego działania wcale nie będzie mniej ze sobą wzajemnie zintegrowany… ale to nie temat na teraz.
Moja "subiektywna prawda" jest jaka jest: to pod programistę powinno być obmyślane środowiko projektowe. Piszę to widząc, że sam programować będę o wiele mniej niż jeszcze 2 tygodnie temu.
[quote]Na koniec odniosę się do "TFS podobnie jak każdy podobny tool narzuca (…)". Nie każdy. Z TFSem jest taki właśnie problem, że zbyt wiele narzuca. I narzucane rozwiązania są bardzo często bez sensu. Podział na programista/nieprogramista zauważyłem, ale ja uważam że to programiści są najważniejsi w całym tym galimatiasie. I to oni najwięcej cierpią przy TFS, często nawet nie zdając sobie z tego sprawy.
No ale nie przeciągając – zapowiedziałem przedstawienie leku (przynajmniej częściowego) na to zło, gdzie i wilk syty (tzn meneżer ma swoje wykresy) i owca cała (programista może wygodnie pracować).
I jeszcze standardowe pytanie: czy pracowałeś z czymś innym? Nie SVN lub VSS, ale git hg czy bazaar? Jeśli nie to dyskusję tą znam na pamięć i nie ma sensu się w nią po raz kolejny zagłębiać.[/quote]
Maćku,
Myślę, że niezgodność zdań wynika w tym przypadku z rozbieżności oczekiwań.
To czy ograniczenia narzucane przez TFS’a (a właściwie przez Team Explorera) są sensowne – nie mnie oceniać. Tak jak już pisałem, pracuję od kilku lat z TFS’em właśnie i mogę Cię zapewnić że jako nie jest on taki zły jak może się z początku wydawać. Zresztą większość wymienionych przez Ciebie "niedoskonałości" to wady zestawu klienckiego tzn "Visual Studio" oraz "Team Explorera", a nie TFS’a który sam w sobie jest (oczywiście w uproszczeniu) tylko bazą danych z zestawem web service’ów umożliwiających dostęp do niej.
Wydaje mi się, że Twoja negatywna ocena wynika w dużym stopniu z tego, że oceniasz omawianą aplikację wyłaczenie w kategoriach repozytorium kodu. W takim przypadku prawdopodobnie masz rację – być może na rynku istnieją lepsze narzędzia służące do tego celu (jak chociażby wymienione przez Ciebie powyżej).
Ja natomiast widzę Team Foundation Server w kategoriach narzędzia służącego do zarządzania cyklem życia aplikacji (ALM), który jak wiemy składa się z większej ilości etapów niż tylko "check-in’owanie" i "check-out’owanie" kodu. Absolutnie nie zgadzam się również ze stwierdzeniem, że "programiści są najważniejsi w całym tym galimatiasie". Są jak najbardziej ważni, ale nie bardziej niż analicy, architekci, zespół QA i cała reszta. Zarządzanie wymaganiami, planowanie projektu, procesu testów, zarządzanie błędami oraz przede wszystkich WSPOMAGANIE PRACY CAŁEGO ZESPOŁU – tego oczekuje od nowoczesnego narzędzia do pracy w projekcie. I tego niestety nie oferuje żadna z wymienionych przez Ciebie aplikacji.
Tak więc podsumowując – ocena TFS’a jako repozytorium kodu z zestawem raportów dla managerów – jest według mnie, delikatnie mówiąc, krzywdząca.
No dokladnie, albo jedno zintegrowane, albo sobie skladamy.
Znam wtedy takich co twierdza, że git + gource jako platforma do raportó oraz text mate to wszysto czego potrzebuja do szczescia.
Wtedy pozostaje pytanie co to za projekt i jak realizowany, bo dla wielu być może faktycznie to może być prawda.
Witam,
ja tez od stycznia w nowym zespole i też z TFS (ale dla mnie to pierwszy raz).
Osobiście nic do TFS nie mam, tylko nasłuchałem się jadu od wielu ludzi. Nie jest taki zły jak już się trochę człowiek przyzwyczai (np. nie wiedziałem co z czym się je i przypadkowo wycheckinowałem cały projekt). Jest wiele rzeczy które mi się nie podobają (właśnie checkinowanie – bez sensu), ale da się z tym żyć. Ponieważ nie mam wyboru to nie narzekam i się przyzwyczajam (a prywatnie używam gita i Ruby :D ).
Na szczęście pracować będę raczej w elementach systemu mało ruszanych przez innych, ale czekam na kolejny post, który może poprawi moje warunki pracy z TFS :)
oczywiście miało być wycheckoutowałem :D
Nie ma co się czarować i upiększać rzeczywistość jak "wolne media". TFS to koszmar. Kto posmakował pracy choćby z svn’em nie mówiąc już o gicie czy mercurialu ten nigdy nie chce wracać. Najlepsze są teksty, że już w wersji 11 (2012 rok!) coś poprawili. Można czekać do wersji 2017 aż w końcu poprawią wszystko – tylko po co? Moim zdaniem i tak MS w końcu przejdzie na rozproszony system kontroli wersji i wtedy będzie można znów się zastanowić nad TFS’em. Tymczasem życie jest za krótkie żeby się z tym użerać :)
Kolejny ciekawy post :)
Ja również pracowałem z TFS łącznie ponad rok w dwóch projektach z czego w jednym byłem programistą a w drugim scrum masterem. Projekty co prawda zakończyły się sukcesem, ale o TFS mogę powiedzieć tyle, że działa on woolllnnnnoooooooo… Oczywiście zgadzam się, że TFS jest dość wszechstronnym narzędziem i można się przyzwyczaić do nieco innej pracy z nim, ale jednak prędkość działania najbardziej nam przeszkadzała. Nie chodzi nawet o to, że powoduje to jakieś wielkie opóźnienia, ale raczej o to, że rozbija pracę i dekoncentruje – nie wspominając już o ilości wykrzykiwanych WTF ;)
Dlatego gdybym teraz rozpoczynał jakiś projekt, albo dołączał do zespołu jako team leader, optowałbym za zmianą narzędzia na kilka alternatywnych, które choć nie stanowią jednej całości, to jednak są po prostu wygodniejsze.
pozdrawiam
Sławek P.
unodgs,
Obiło mi się o oczy że "rozproszoność" TFSa jest w roadmapie, ale nie w v11, nie w następnej, ale jeszcze w następnej:) Chociaż może to tylko tępe plotki, a co gorsza nie mam nawet żadnego linka żeby pokazac gdzie to widziałem, pewnie gdzies na twitterze.
pawelek,
Jeśli znasz Gita i nie narzekasz na TFSa to jesteś chyba bardzo tolerancyjny:). Nie znam nikogo kto by tak powiedział w Twojej sytuacji.
Nie no – narzekam na TFS, ale nie aż tak. Póki to tylko source control, to mogę używać winmerge + Notepad++ tak jak przy gicie zresztą. Cóż mi więcej trzeba. A może po prostu jestem mało wymagającym użyszkodnikiem :)
Jeżeli o mnie chodzi to shelve bardziej mi się podoba niż gitowy stash. Za to branchowania prawie wcale nie używam, więc mi TFS’owe nie przeszkadza, bo nawet nie sprawdzałem jak działa. I to w sumie tyle z opcji przeze mnie używanych. No i jak wspomniałem poprzednio – nie podoba mi się checkout. Dlaczego nikt inny nie może pracować na edytowanym przeze mnie pliku. Konflikty powinien rozwiązywać ostatni który wrzuca zmiany, a nie takie powstrzymywanie innych przed pracą :)
Pozdrawiam
pawelek
pawelek,
Już z czystej ciekawości – czemu shelve bardziej Ci odpowiada niż stash? Temu że jest wysyłany na serwer, czy ma jakieś jeszcze ukryte właściwości?
Nie używałem i nie używam TFS-a (moja, świadoma decyzja, jak poczytałem sobie w o nim necie).
"Dlaczego nikt inny nie może pracować na edytowanym przeze mnie pliku." – tego naprawdę nie da się jakoś ustawić? A co z plikiem projektu? Nawet w vss dało się to przestawiać.
Oczywiscie, ze moze. To jakis mit jest. Albo nieprawidlowa konfiguracja polis
Artur, Xxx,
Oczywiście że się da, ale wiem że niektóre zespoły tak konfigurują TFSa żeby uniknąć potem piekła merge… które w TFS nie wyszło jeszcze z epoki kamienia łupanego.
Ja jestem podobnego zdania co autor – z TFSem miałem do czynienia przez pół roku i było mi bardzo ciężko się przyzwyczaić… Diffowanie jest straszne… Może kiedyś przy następnym podejściu i przy nowszej wersji dam się przekonać, ale jak na razie to narzędzie po prostu mi nie odpowiada i zamiast pomagać utrudnia pracę (jako programiście). Natomiast do zarządzania taskami itp. to rzeczywiście całkiem przyjemne narzędzie.
PS U mnie TFS był zauważalnie wolniejszy od SVN, czasami łapał jakieś większe spowolnienia, ale podejrzewam, że to była wina konfiguracji sieci.
Ja z kolei mam dokładnie odwrotne doświadczenia. Przez około rok pracowałem wyłącznie z TFS – jak dla programisty BARDZO podobało mi się. Z SVN korzystam teraz w pracy (około 6 miechów) i wcześniej przez parę lat dla mniejszych projektów – zawsze napotykałem na jakieś "dziwne" problemy. Przez rok pracy z TFS kompletnie nie miałem jakichkolwiek niegodności. Nawet jako projekt open-source zdecydowałem się użyć TFS a nie SVN. Podoba mi się np. łatwe przypinanie task’u do check-in’a.
Jak tak patrze na komentarze (np. "Dlaczego nikt inny nie może pracować na edytowanym przeze mnie pliku") wydaje mi się, że problemy głównie spowodowane są przyzwyczajaniem do innych rozwiązań i brakiem wystarczającej wiedzy o TFS…
Piotr,
Dobrą alternatywą dla TFS nie jest bynajmniej SVN. A co do komentarzy (szczególnie tego o edytowaniu plików na których pracuje ktoś inny)… na to nie ma wpływu programista tylko osoba konfigurująca TFSa.
procent,
Jak to nie ma wplywu?Przeciez typ edycji (blokady) ustawia programista…
Piotr,
Aha, ok. To inaczej: może być zalecenie "z góry", żeby robić exclusive locks z powodu kłopotów z merge. To się chyba zgadza?:)
Z tego co pamiętam można wybrać kilka różnych typów locków przy checkoucie:
– brak – domyślny dla plików tekstowych
– zablokowany checkin – inna osoba wycheckoutuje taki plik ale nie zrobi już checkina, dopóki osoba ustawiająca locka nie zrobi checkin lub nie zdejmie locka
– exclusive – nie można zrobić checkout pliku, domyślne dla plików binarnych
To jest domyślne zachowanie, jeśli u kogoś jest inaczej, to znaczy że admini TFSa się nie popisali, albo jakiś programista jest mało ogarnięty, że wszystko lockuje :)
@procent:
Ale to nie ma nic wspolnego z konfiguracja przeciez. Jesli ktos z gory daje zalecenie to jest to tylko wewnetrza sprawa teamu a nie klopot zwiazany z TFS.
Bartek wymienil 3 opcje. My korzystalismy z "zablokowany checkin".
Piotr,
Oczywiście, ale samo zalecenie jest już bezpośrednią pochodną problemów z TFS i merge.
Co do zablokowany checkin – no proszę Cię, nie mów że to jest dobre rozwiązanie:). Skończyłeś feature i nie możesz go pchnąć do repo, bo ja nie skończyłem swoich zmian…? Więc pracujesz dalej, generując kolejne zmiany, niemające nic wspólnego z kodem którego nie możesz wysłać. Efekt: wielkie checkiny dotykające X różnych tasków.
Tak, wiem, że można wybierać pliki do checkin. Ale gdy w jednym pliku znajdą się zmiany z dwóch zadań to już tego tak prosto się nie rozwiąże (chyba że TFS ma coś analogicznego do git add patch).
@Procent
Mozesz sobie wybrac unchanged opcje(bez blokady). Ale zwykle jesli dwie osoby pracuja nad tym samym plikiem oznacza to poor design przeciez. A jesli juz sie tak zdazy to wybierasz pierwsza opcje i tyle.
Piotr,
Poor design czy nie – na tym poziomie to w ogóle bez znaczenia. Nie muszę w kilka osób pracować koniecznie nad jedną klasą C# (chociaż nawet gdybym chciał to narzędzia nie powinny mi w tym przeszkadzać) – mogę na przykład modyfikować skrypt generowania danych testowych. A ktoś obok może też chcieć go tknąć. Jak wybiorę bez blokady to się pochlastam przy merge.
Ale dyskusja robi się chyba czysto akademicka. Ja tylko twierdzę, że to są OGRANICZENIA. Nie lubię ograniczeń. Narzędzie ma się dostosować do mnie, a nie ja do narzędzia.
Nie ma ograniczen. Napisales na poczatku ze to kwestia konfiguracji admina a to przeciez nieprawda bo kazdy programista moze ustawic tryb blokady i w czym problem?
Piotr,
Jakakolwiek blokada to ograniczenie. A jeśli brak blokady == piekło przy merge (bo po to jest przecież blokada, aby go uniknąć?) to nie bardzo mamy wyjście.
Poza tym, jeśli mogę konfiguracją SWOJEJ maszyny zablokować pracę zespołu to mi się to nie podoba.
Akurat Merge rowniez robi sie duzo latwiej niz w SVN. A blokade mozna w kazdej chwili zdjac (kwestia uprawnien).
"Poza tym, jeśli mogę konfiguracją SWOJEJ maszyny zablokować pracę zespołu to mi się to nie podoba."
Tak samo ze swojej maszyny mozesz wywolac konflikty itp – wiec to nie argument. Zly commit w svn i tez popsujesz prace innym…
O kurcze, ale dyskusja :)
Dzięki shelve (które oprócz, że wolniej, nie działa gorzej niż stash) mogę przesyłać moje zmiany do członków teamu. Zero konfiguracji i innych. W gicie najprościej zrobić path i wysłać mailem, jest i wiele innych opcji, ale shelve w tym wymienianiu przypadł mi do gustu.
Jestem początkującym użyszkodnikiem TFS. Dopiero się uczę.
Checkoutowanie domyślnie nie zakłada żadnych ograniczeń – ja sobie pogrzebałem tylko. Ale już naprawiłem i jest ok.
w gicie zrobić patch miało być :)