Święte słowa. Niestety w niektórych firmach TFS jest jedynym słusznym VCSem - i, co gorsza, decydują o tym ludzie, którzy na codzień nie pracują ani z kodem ani z VCSem. Smutne.

Czesc! W naszej firmie zastanawiamy się nad przejściem z VSS na coś nowego, ponieważ używamy .NETu i VS2010 naturalną drogą wydaje się własnie TFS. Jednak co jakiś czas napotykam się na posty krytykujące TFSa, nie wymieniające jednak konkretnych powodów dlaczego jest on zły. Przydałby się post z listą zarzutów wobec TFSa. Pozdrawiam!

To żeś Procent przytoczył argument... Dla porównania wyguglaj coś o czymkolwiek innym (GIT: http://www.google.com/search?q=why+git+sucks   SVN: http://www.google.com/search?q=why+svn+sucks).
Nawet pokusiłem się o przeczytanie pierwszego artykułu napotkanego z tytułem "why tfs sucks" (www.nearinfinity.com/.../...tfs_-_team_found.html) i z większością rzeczy w tym artykule się nie zgadzam.
Nie mam wielkiego porównania z innymi tego typu narzędziami ale na ten moment TFS jest dla mnie niezastąpionym narzędziem pracy (mówiąc z perspektywy doświadczonego programisty i kierownika projektu).

Nie napisałem że nie mam w ogóle doświadczenia z innymi tego typu narzędziami, zdarzyło mi się trochę pracować na SVN'ie i te narzędzie nie przemawia do mnie. Napisałem że nie mam wielkiego doświadczenia - czyli nie pracowałem więcej niż pół roku z żadnym innym niż TFS.
Jednakże rozmowa ta powinna obejmować trochę szerszą tematykę, powinniśmy raczej mówić o narzędziach pozwalających pracować w zespole / pozwalających zarządzać całym cyklem życia projektu. Ciężko jest wypowiadać się o TFSie jedynie w kontekście repozytorium kodów bo lwia część TFS'a dotyczy samego zarządzania projektem. Nie znam drugiego takiego narzędzia które miałoby to wszystko w jednym, jakieś przykłady?

I jeszcze zapomniałem dodać jednej kwestii do ogółu.
Patrząc na ludzi w zespole (a nawet w dwóch zespołach) jak pracują z TFS'em to faktycznie zdarza im się źle wyrażać o TFS'ie. Ale w wiele przypadków wnikałem głębiej i okazywało się że to programista sam coś skopał czegoś niedopilnował albo po prostu nie umie czegoś ustawić (bądź nie wie że można).

Chciałbym się dowiedzieć dlaczego kod w TFSie nazywasz "niezorganizowaną kupą tekstu"?

A może masz ochotę opisać jak (do czego) praktycznie wykorzystujesz funkcje branch i merge.
Przyznam szczerze że rzadko korzystałem z tych funkcjonalności, do tej pory nie widziałem wielkiej potrzeby (może charakterystyka projektów ma na to wpływ?). Może mnie zainspirujesz i spróbuję zrobić to samo na TFS'ie :)

I pracujesz jako pięciu programistów na raz? :)
Tzn samo podejście jest w porządku, ale nie widzę głębokiego sensu stosowania takiego podejścia w zespole liczącym 3 programistów, testera, designera i kierownika projektu. Poprawianie błędów w oddzielnym branchu to jest ok, żeby nie wdrażać nowych funkcjonalności dla klienta przed zaplanowanym czasem.
Ale wracając do TFS'a - ten przypadek który opisałem spokojnie można zrobić na TFSie i wszystko ładnie jest widoczne. Bardziej skomplikowane przypadki branch i merge także są na TFSie realizowane (szczególnie w wersji 2010).
Jeżeli chodzi o przyglądanie się które commity odnoszą się do jakiego wymagania/zgłoszenia/zadania to na TFSie wystarczy wejść w szczegóły danego zadania i już widać wszystkie powiązane changesety z tym zadaniem.
Mam nadzieję, że to nie jest Twój jedyny słuszny argument przeciwko TFS'owi.

Przyznam szczerze, że z chęcią spróbowałbym alternatywy (żeby wyrobić sobie klarowne porównanie) z tymże brak okazji.
A jeżeli chodzi o Twoje argumenty przeciwko TFSowi to chyba faktycznie nie używałeś go już od bardzo dawna :) I to właśnie chciałem podkreślić nie wysuwaj argumentów bazując na doświadczeniach sprzed x lat, a właściwie piszesz jakbyś pracował kiedyś jeszcze nie na TFS'ie a na Source Safe :)
Najpoważniejszy i niepodważalny argument przeciwko TFSowi to to że nie jest darmowy, ale jak firma może sobie na TFSa pozwolić to nie widzę żadnych innych przeszkód czemu z niego by nie korzystać.

Ale w maluchu jestem w stanie Ci przyznać rację że w Farri musi być po prostu lepiej. W przypadku TFS'a ja nie czuję żadnego powodu dla którego miałbym zmieniać repozytorium kodów. Po prostu jest to w całości zadowalające narzędzie a ostatnio nawet potrafi mnie mile zaskakiwać. Mówiąc o TFSie ja sie nie zastanawiam jak ulepszyć składowanie kodu a jak ulepszyć proces wytwarzania oprogramowania. Jaki przyjąć flow w kontaktach programista-tester-kierownik projektu.

Moim zdaniem ciągnięcie tej dyskusji też nie ma żadnego celu - jedyne co chciałem podkreślić, to to że nie akceptuję jak ktoś wypowiada się o produkcie (szczególnie gdy podejmuje ostrą krytykę) nie znając jego możliwości. Jak zwolennik TFS'a chyba sam rozumiesz że musiałem podjąć tą dyskusję :)

Ta, zażarta dyskusja :)
W swojej aktualnej pracy przeforsowałem wprowadzenie GIT-a zamiast MS VSS. Scentralizowany system, blokowanie plików i wiele wiele innych (w tym praktycznie brak możliwości tworzenia Branchy - przynajmniej praktycznych) doprowadzały zespół do szału i wielu problemów.
GIT sprawdza się w codziennej pracy w tak kosmicznych scenariuszach, że nawet w najśmielszych snach nie mogłem ich przewidzieć :) W VSS rozpoczęcie pracy nad plikiem często gęsto stawało się mordęgo i wiązało się z wycieczką do Pana X który aktualnie nie odbiera wiadomości na skyp-ie a wypadało by, żeby odblokował zajmowany plik (w takich sytuacjach najczęściej okazywało się, że "coś tam" ma do skończenia i finalnie wszystko kończyło się kopiowaniu plików lub odpinaniu od repo). Nie wspomnę już o mergowaniu - tylko staży programiści z brodą i rozciągniętym swetrem są w stanie to ogarnąć w VSS.
Trzeba przyznać, że na początku bardzo ciężko było mi (anty konsolowo - linuxowemu człowiekowi) się przyzwyczaić do GIT-a, ale po 6-8 miesiącach nie zamienił bym tego systemu na żaden inny a już na pewno nie na scentralizowany.
Przewaga systemów zdecentralizowanych nad scentralizowanymi jest faktem i nie ma się co sprzeczać.
Argument że TFS jest do wszystkiego.... wiadomo :)

MS VSS to faktycznie było dno - w TFS teraz już nie ma czegoś takiego jak blokowanie pliku (można to właczyć ale jest to opcja domyślnie nie włączona). I wiele innych problemów (m.in. z branch i merge) też zostało sensownie rozwiązanych. Może faktycznie jakichś scenariuszy związanych z repozytorium kodu nie da się w nim zrobić, ale dla mnie TFS to jest przede wszystkim narzędzie do kontroli projektu pozwalające zarządzać pracą programistów, monitorować ich postępy, szukać historii zmian w projekcie w powiązaniu z wymaganiami (jeżeli klient mówi że coś miało być inaczej). Kod do repozytorium wrzuca się przyjemnie prawym na projekt "check in" i już. Nawet jak wystąpią konflikty to z większością radzi sobie sam (a jak nie radzi to też jest dobre narzędzie do rozwiązywania konfliktów). Daje możliwość powiązania dodatkowych "sprawdzaczy" do check ina, typu sprawdzenie kodu StyleCop'em (i nie pozwolenie wcheckowania) czy jakieś inne wymyślne reguły. Jako kierownik projektu w notyfikacjach dostaję zielone bądź czerwone powiadomienie jak ktoś wrzucił checkina i jego build się powiódł lub nie. No po prostu repozytorium spełnia swoją funkcję i mogę się skupić na ważniejszym aspekcie definiowania/poprawiania procesu wytwarzania oprogramowania (dostosowywać szablony procesu według utartych zwyczajów w firmie i kolejnych doświadczeń).

Jeżeli chodzi o GIT'a to na pewno tego nie krytykuję, chciałbym spróbować, ale nie usłyszałem jeszcze żadnego argumentu który choć trochę przekonałby mnie do tego (bądź innego) rozwiązania, nie widzę jak GIT mógłby przyspieszyć moją codzienną pracę (bo o to w tym wszystkim chodzi).

Z mojej perspektywy (programisty) ciężko mi by się teraz pracowało bez takich dodatków jak:
stash
reflog
reset (soft/hard)
chery-pick
remote's

To jest tylko kilka przykładów, ale naprawdę bardzo, ale to bardzo przydatnych (stasha używam kilka razy dziennie). Odnośnie powiadamiania i innych fajnych dodatków - można tutaj zrobić praktycznie wszystko, chodź nie jest to za naciśnięciem jednego przycisku :) W firmie wykorzystujemy z powodzeniem powiadomienia o push-ach na główne repo.
Nie wiem jak z perspektywy kierownika projektu, ale programistą, już sam rozproszony charakter GIT-a, znacznie przyspiesza pracę- większość rzeczy nie przechodzi przez główne (produkcyjne) repozytorium, można swobodnie wymieniać się zmianami, nie tracąc przy tym kontroli na kodem.

A możesz po krótce opisać co te dodatki robią i w czym Ci usprawniają pracę?

TFS to nie tylko system kontroli wersji. TFS to połączenie w jedno wiele narzędzi. Największą jego zaletą jest że wszystkie informacje o projekcie są w jednym miejscu. Oprócz repozytorium kodu TFS daje rejestracje bugów, zadań, raporty, automatyczne buildy itd. Dla większych firm  takie ujednolicone repozytorium dla wszystkich projektów to duża wartość.
Czy w gicie możesz w łatwy sposób powiązać zdanie ze zmianami w kodzie ? W TFS-ie robisz polisy które wymaga wybranie Work Item przy check-in i wiesz dokładnie jakie zmiany związane są z konkretnym bugiem czy zmianą.

Procent,
chodzi mi o to że porównywanie TFS z systemem kontroli wersji ponieważ TFS to system do "zarządzania projektami".

Jeżeli jakaś firma posiada licencję na TFS-a to naturalne jest używanie tego narzędzia "out-of-the-box", jest świetnie zintegrowany z Visual Studio i od wersji 2010 instalacja jest naprawdę prosta.

Używanie TFS-a tylko do kontrolę wersji dla mnie mija się z celem.

Co do samej kontroli wersji to dla kilku-osobowego zespołu projektowego w firmie wystarcza, chociaż na pewno nie jest tak dobry jak Git.
Przejście z TFS-a na Git-a oznacza uczenie się nowego narzędzie przez wszystkich deweloperów oraz rezygnację z integracji z TFS-em.
Musiałbym mieć mocne argumenty żeby to zrobić (a już przekonanie o tym PM-a nie wchodzi w grę).

Ale przekonałeś mnie żeby wreszcie znaleźć czas i pobawić się tym Git-em w domu,  do tej pory używałem VSS, SVN i TFS.

Procent
Moim zdaniem trochę za dużo powiedziałeś w zdaniu "używanie narzedzia przeszkadzającego w pisaniu kodu". Żeby rzeczywiście te narzędzie przeszkadzało mi w czymś, nie pozwalałoby mi być produktywnym to po prostu bym go nie używał szukałbym alternatyw. W mojej codziennej pracy TFS pomaga mi wielu zadaniach i w tej chwili nie wyobrażam sobie pracy bez niego. To o jakim przeszkadzaniu tu mowa skoro dzięki temu narzędziu jestem bardziej produktywny?
Żeby przejść na inne narzędzie typu GIT potrzebne mi są konkretne argumenty mówiące o tym jakie moje problemy te narzędzie rozwiąże, w jakich chwilach w mojej codziennej pracy zrobię coś szybciej. Do tej pory takich argumentów po prostu nie usłyszałem, a pisanie żebym sobie poczytał jakąś książkę nie jest na miejscu bo mógłbym poczytać również książkę o TFSie i skorzystać jeszcze z większej ilości jego dobrodziejstw.

Podkreślę jeszcze raz, moim zdaniem za bardzo jedziesz po tym produkcie skoro go na codzień nie używasz.

@Procent
"używanie narzedzia przeszkadzającego w pisaniu kodu" - tutaj to się chyba trochę zagalopowałeś :)
Tak jak w "Seksmisji" :
- [Albercik] A może Curie-Skłodowska też?! (... była kobietą)
– [Maks] To akurat nie najlepszy przykład...