Spędziłem cały ranek próbując coś sprawdzić - teraz zdaję sobie sprawę, że straciłem kilka dni pracy.

To zdarzyło się wcześniej - i podobno jest częstym zjawiskiem w SourceSafe. Czy można używać SourceSafe bez problemów, a jeśli tak, to w jaki sposób?

Mój widok jest prosty, migruj do czegoś innego jak najszybciej. To nie potrwa długo (1-2 tygodnie WAG) i bez względu na to, jak długo trwa migracja, łatwo to uzasadnić kosztami zarządzania. Trochę czasu na migrację to solidna kontrola źródła i bardzo mała szansa na utratę kodu źródłowego. Wykonaj szybkie wyszukiwanie w Google „źródłowych bezpiecznych opowieści grozy” lub podobnych, jeśli twój szef jest sceptyczny.

Najgorszy. SCM. Zawsze.

Wszystko, co jest złe w SCM, jest zawarte w VSS. Nawet StarTeam jest lepszy niż Source Safe. Source Safe to Internet Explorer 1 w świecie kontroli wersji: całkowicie zastąpiony przez każdą inną implementację.

Jak tego użyłem?

Mój typowy proces roboczy polegał na wykonywaniu zadań

1. Sprawdź projekt
2. Zablokuj wszystkie pliki (aby uniknąć scalenia z kimkolwiek, kto otworzył bezbożne bramy piekła)
3. Wykonałem moją pracę
4. Każdego dnia sprawdzałem moje zmiany
5. Sprawdziłem to wszystko ponownie i naprawiłem wszystkie problemy z integracją
6. Sprawdziłem to z powrotem

W porównaniu z Subversion, powyższe jest śmieszne (poza sprawdzeniem, czy nie złamałeś kompilacji).

Ograniczenia praktyk programistycznych mojego zespołu

Są to zasady, zgodnie z którymi zespół musiał pracować, aby działał dla nas. Twój przebieg może się różnić.

1. Tylko jedna osoba może edytować plik (Niebo pomoże ci, jeśli pojedzie na wakacje)
2. Nie rozgałęziaj, zarządzanie jest zbyt trudne
3. Nigdy nie próbuj wracać do poprzedniej wersji

Co można zrobić?

Polarion ma dobry zestaw narzędzi do migracji z programów takich jak Source Safe na Subversion (SVN), który jest obecnie de facto standardem w większości przedsiębiorstw do kontroli wersji open source. Subversion cierpi z powodu tego, że serwer musi być dostępny, aby zezwalać na meldowanie się (w przeciwieństwie do GIT lub Mercurial, które są zaprojektowane dla rozproszonych zespołów offline).

Zmień kontrolę źródła na SVN / Mercurial / Git i nigdy nie oglądaj się za siebie!

Wyłączyliśmy go z eksploatacji około rok temu.

Zdarzyło się kilka razy, że tego, co zameldowałem się poprzedniego wieczoru, po prostu nie było następnego dnia rano. Nie wydawało mi się to zabawne, ponieważ wyglądało podejrzanie, jakbym właśnie skończył pracę. Ponieważ byłem nowy w firmie, mogło to być dla mnie niebezpieczne.

Przeszliśmy do TFS i od tego czasu działa płynnie.

Mój widok?

Są lepsze, łatwiejsze w użyciu, bezpieczniejsze w użyciu i całkowicie bezpłatne. Po co w ogóle zawracać sobie tym głowę?

Jest to jeden z obszarów rozwoju, w którym mamy duży wybór; większość lub wszystkie lepsze niż VSS.

• Obalenie
• Bystry
• Git
• Więcej

Używanie SourceSafe w operacji komercyjnej jest jak ogrzewanie budynku przez spalanie banknotów dolarowych.

W 2000 r. Moja ośmio-programistyczna firma prawdopodobnie straciła 5–10% swojej produktywności z powodu średnio dwa razy dziennie uszkodzeń bazy danych VSS. Było tak niskie, ponieważ chodziliśmy na cogodzinne kopie zapasowe.

Od czasu przejścia z VSS do Perforce, svn i git, nigdy nie miałem uszkodzonej bazy danych SCM.

Mogę zagłosować w tej sprawie do piekła, ale ...

VSS skutecznie nakłada na ciebie narkotyki, do tego stopnia, że ​​nie możesz pogodzić się z rzeczywistością potrzebną do zrozumienia, że ​​twoje zepsute repo nie było twoją winą.

Proszę, nigdy tego nie używaj.

używałem go przez lata - było to domyślne rozwiązanie, ponieważ już tam było. Gdyby mnie ugryzł kilka razy, ale bezwładność jest trudna do pokonania

potem musiałem używać go zdalnie przez VPN, a nawet drobne meldunki przypominały wpychanie cegły przez otwór . Szybciej było ręcznie znaleźć zmienione pliki, spakować je, wysłać pocztą e-mail, zdalnie do źródłowej maszyny skarbca, rozpakować je i sprawdzić kod z maszyny skarbca źródłowego.

Przełączono na Mercurial. Mogę sklonować całą bazę kodu źródłowego w sieci VPN w niecałą minutę. I nie boję się już rozgałęziania.

Nigdy nie wracam

To obrzydliwość. Ale wciąż lepiej niż nic.

Używałem go przez długi czas (prawie 10 lat) bez żadnych osobistych problemów (w tym w zespołach, w których pracowałem, chociaż nasz kod był dość dobrze podzielony, aby uniknąć konfliktów itp.).

Ale jest zbyt wiele historii utraty danych, aby móc z nich korzystać, gdy istnieją przyzwoite, niezawodne alternatywy open source.

Edycja: z komentarzy wydaje się, że w wiadomościach nie ma nic złożonego (rozgałęzianie, scalanie, konflikty) i prawdopodobnie nic ci nie jest. Coś więcej i wybierasz się na ryzykowne terytorium.

Nawet stwardnienie rozsiane wycofuje się na korzyść TFS.

W przypadku solo lub naprawdę małego sklepu pracującego w Visual Studio 6 lub czegoś starszego jest to znośne i lepsze niż nic. Myślę, że jest wiele przesady w tym, jak źle było, ale potem wystarczy jeden przypadek utraty cennej pracy, aby zakwasić cię produktem (nie bez powodu). VSS miał swoje miejsce i zasługuję na to, aby zachęcić wielu programistów, którzy nie używali żadnego narzędzia SCM, do nawyku, ale podobnie jak wiele technologii, jest on już prawie przestarzały.

Po 3 latach używania go, narzekania na mojego kierownika z powodu wszystkich bardziej zaawansowanych / racjonalnych alternatyw, nigdy tak naprawdę nie miałem problemu z VSS, ale nigdy nie miałem opcji.

Moim zdaniem jest to zarówno do bani, jak i do ciosów.

Najbardziej irytujące jest to, że nie jest to okropne przechowywanie wersji i myląca możliwość rozgałęziania, ale pole listy w menu plików nie pozwala nacisnąć klawisza strzałki w prawo, aby rozwinąć.

Naprawdę bolesne.

Mój pogląd na VSS? Odrzuciłem kilka ofert pracy (bardzo dobrze płatnych), ponieważ poprosili o „biegłość w VSS”. I jestem pewien, że jest tu kilka innych osób, które zrobiły to samo.

Nie tylko cierpisz na problem potencjalnego uszkodzenia źródła (który powinien być wystarczającym argumentem, aby kierownictwo go zastąpiło), ale także musisz żyć z niewygodną kopią zapasową i niezdolnością do efektywnej pracy jako zespół nad różnymi strumieniami pracy.

Znajdź inny SCM (dowolny inny) i sprawdź, jak łatwe może być rozgałęzianie i scalanie. Pomyśl o tych czasach, kiedy musiałeś skopiować pliki z rozwiązania VSS i trzymać je gdzie indziej, gdy wróciłeś, aby naprawić błąd w kodzie „produkcyjnym”.

Aby kopać, po prostu zainstaluj GIT - skieruj go na pliki VSS i przekonaj się, jak łatwo GASP dwóm programistom może pracować w różnych częściach tego samego pliku W TYM SAMYM CZASIE, a następnie niech oprogramowanie inteligentnie scali twoje zmiany ... SCM narzędzia powinny być czymś więcej niż tylko źródłową kopią zapasową.

Moje poglądy na VSS? Używałem go przez długi czas regularnie (nadal sporadycznie używamy do starszych komponentów), ale dla naszego zespołu jest to zbyt XX wiek:

• Bardzo niewiarygodne
• Nieużywalne oddziały
• Bardzo słaba obsługa wersji, masz etykiety, ale (podobnie jak oddziały) tak naprawdę nie nadają się do użytku

Jestem z wszystkimi powyższymi: wybierz jedną z lepszych alternatywnych rozwiązań typu open source (nawet stary CVS) lub, jeśli Twoja firma ma jakąś subskrypcję MSDN, TFS .

• jego domyślne blokowanie spowalniało programistów i nikt nie chciał zadzierać z jego konfiguracją
• nie integruje się zbyt dobrze z innymi usługami, na przykład aplikacją internetową do zarządzania projektami
• nie działało to dobrze z naszym planowanym serwerem CI

Nowy materiał Team Foundation 2010 miał bardzo pomóc i spróbować uciec od złych części VSS. Ale u podstaw wciąż opiera się na VSS , dlatego przenieśliśmy się do SVN.

edytuj - Rozumiem, że TFS jest zupełnie nowy, ale podczas testowania wielu programistów, o które prosiłem, miało do niego bardzo podobne odczucia. Powodem, dla którego powiedziałem „u podstaw” było to, że pamiętam pliki TFS wykonane w moim rozwiązaniu, które wyglądały tak samo jak te wykonane przez VSS. Jest to z punktu widzenia dewelopera, być może nawet nie wiedząc o technologii VSS, TFS lub innego SCM. Przepraszam za jakiekolwiek zamieszanie.

Wcześniej byłem obarczony SCCS pod XENIX. VSS, w Visual Studio 6, mimo wszystkich swoich awarii i problemów miał wyraźne zalety. Nadal używam go do małych projektów i nie używam SCCS w żadnej wersji.

Nie mogę zrozumieć, dlaczego wszyscy chcą badmouth VSS. VSS nie jest dystrybuowany, a kontrola wersji rozproszonej jest

1. lepszy
2. pozwala w praktyce na niepodzielną kontrolę wersji

Przeczytaj to .