Jakie są twoje ulubione systemy kontroli wersji? [Zamknięte]

41

Jest to raczej pytanie dyskusyjne niż faktyczna próba określenia „najlepszego”, ponieważ wyraźnie różni się to w zależności od potrzeb organizacji. Jestem bardziej ciekawy argumentów przemawiających za różnymi systemami w różnych kategoriach (scentralizowane vs rozproszone, otwarte vs zastrzeżone itp.).

Jak myślisz, jaki jest najlepszy system kontroli wersji?

Fishtoaster
źródło
1
en.wikipedia.org/wiki/Comparison_of_revision_control_software to świetna tabela porównawcza do tego dokładnie. Pytanie do dyskusji ... wiki społeczności?
Chris
4
Pierwszy, który opublikuje nazwę, otrzyma rep… To powinna być wiki społeczności.
takeshin
Nie zauważyłem, że jest to już wiki społeczności .
bierze

Odpowiedzi:

81

Bystry

Ze względu na jego wyrafinowaną zdolność rozgałęziania i scalania kodu jest to najlepsze, jakiego użyłem. Cały paradygmat DVCS ma tyle sensu. Nie korzystałem z Git, ale przypuszczam, że również się kwalifikuje.

obrotami
źródło
Muszę wypróbować Mercurial jakiś czas, odkąd już wypróbowałem 2 z dużych 3. A ponieważ Google Code go obsługuje ...
TheLQ
2
Mercurial jest słodki, jeśli używasz Netbeans. integracja IDE jest idealna.
Seun Osewa,
4
Wolę Mercurial po prostu dlatego, że TortoiseHg jest bardziej dojrzały niż TortoiseGit :-) (całe doświadczenie w systemie Windows jest również znacznie lepsze w Mercurial)
Dean Harding
+1, sugeruję uczynić Mercurial pogrubionym i większym (jak zrobił to Gaurav w swojej odpowiedzi)
Tim Post
Mercurial jest całkiem słodki. Ja i mój zespół używamy go od około 2 miesięcy i jest to powiew świeżego powietrza w porównaniu do SVN.
Gary Willoughby,
72

Git

Git jest fantastyczny i szczególnie poleciłbym go każdemu, kto pracuje nad projektami open source: o wiele łatwiej jest wnieść niewielką, jednorazową zmianę do projektu na Git, szczególnie jeśli jest on hostowany na GitHub, niż zajmuje się e- wysyłanie łatek za pomocą SVN.

Jedno duże zastrzeżenie dla użytkowników systemu Windows: narzędzia Git dla systemu Windows, choć zdecydowanie użyteczne, nie są całkiem do zera. Kiedy byłem zmuszony do korzystania z systemu Windows przez jakiś czas, wypróbowałem interfejs systemu Windows Mercurial z narzędziem do integracji Hg-Git, aby móc korzystać z repozytoriów Git, i stwierdziłem, że jest o wiele łatwiejszy w użyciu.

Gauraw
źródło
5
Myślę, że ważne jest, aby powiedzieć, że git jest trudny. Uwielbiam to, ale nie jest to coś, czego można użyć do nauki tego przez kilka dni. Musisz go używać przez chwilę i denerwować się, aż zmienisz zdanie ... ;-)
Khelben,
1
@Khelben - Tak, jest w tym trochę prawdy. Wydaje się jednak, że jest w nim poświęcona największa ilość literatury / artykułów / samouczków w sieci. Regularnie znajduję książki o Git, Mercurial - nie tak bardzo (używam tutaj Mercurial jako kontrastu, ponieważ pod wieloma względami jest podobny do Git). Nie mogę powiedzieć, czy to dobrze, czy źle, ale wygląda na to, że ludzie go używają.
Gawron
2
msysgit można używać w systemie Windows.
1
Zakładam, że git, Mercurial itp. Są całkiem dobre, ale zdecydowałem się na git głównie dlatego, że auf GitHub. GitHub jest ładniejszy niż porównywalne strony i jest tam hostowanych wiele ważnych projektów. GitHub obniża barierę, aby znacznie przyczynić się do Open Source.
LennyProgrammers,
2
Mercurial nie POTRZEBUJE książki.
Warren P
24

Ostrzeżenie: Od tego postu znalazłem Mercurial i uwielbiam go znacznie lepiej niż SVN. Więc ten post jest trochę nieaktualny z komentarzami Pro SVN i ogólną anty-DVCS, ale anty-git jest nadal aktualny


Jestem fanem SVN nad Git.

Dlaczego? Ponieważ SVN był znacznie łatwiejszy dla jednego programisty lub małego zespołu, a git (konkretnie msysgit) pozostawił mi zły smak w ustach.

Kiedy pracowałem w małym sklepie, zapoznałem się z Git na Windowsie. Natychmiast zauważyłem, ile pracy wymagało, aby pracować z Githubem. Najpierw musiałem wygenerować klucz prywatny ssh, wkleić klucz publiczny w Github, a następnie przywołać pageant i otworzyć mój klucz prywatny za każdym razem, gdy chciałem pchać, co było bardzo denerwujące.

I tak naprawdę nigdy nie podobało mi się, że niszczę całe repozytorium. Przyznam, że nigdy nie pracowałem z niczym wielkim, ale bałbym się pobrać repozytorium KDE w Git, jeśli całe repozytorium i jego wersje są na moim HD.

Potem był mylący proces zatwierdzenia. TMK, musiałem najpierw „wyrównać” wszystkie pliki, które chciałem zatwierdzić (co było do bani, gdy masz wiele plików, zajęło mi trochę czasu, aby znaleźć polecenie ręczne, aby wszystko wyrównać), a następnie wykonać zatwierdzenie, a następnie przesunąć do głównego repo (dlaczego to osobna operacja ?!).

Miałeś także niezbyt (!) Bardzo pomocne dane zatwierdzenia. Och, spójrz, to jest 14f74433245ae17aeeaa część drzewa 2167a4934d0a4a7db0de i rodzic d7042abb4821d3faf600. Do diabła, czy to znaczy? Powinienem być w stanie dość szybko rozgryźć sprawę i nie musiałem sprawdzać dziwnej dokumentacji.

Mówiąc o dokumentacji, przynajmniej kiedy jej używałem, wydawało się, że wszystko jest w formacie linux man, IE jest dla mnie mylące i bezużyteczne. Rzadko mogłem znaleźć dużo pomocy w dokumentach i po prostu skorzystałem z google.

A w przypadku zatwierdzeń jedyną rzeczą, która mi się nie podobała, był brak numerów wersji. Teraz wiem, że dzieje się tak z powodu projektu git, ale każde oprogramowanie wymaga numeru wersji. Nadal pamiętam zatwierdzenia znaczników, które pojawiałyby się z komunikatem „Zmieniono wersję na 1.8.6” lub coś podobnego, ale nadal nie można było budować liczb. Dla mnie wersja 1.8.6.5164 (ostatnia część to numer wersji) mówi mi znacznie więcej niż tylko 1.8.6 i notatkę informującą, że coś drobnego się zmieniło, spróbuj

Bazując na oprogramowaniu, podstawowym programem w systemie Windows jest msysgit, co jest okropnym interfejsem. Kilka razy mnie zablokowało, miało okropny interfejs, a integracja CLI-GUI była co najwyżej niepewna. Wokół mnie ćpunowie z linii poleceń jeszcze bardziej nienawidzili gui.


Teraz spójrzmy na SVN. A ponieważ jestem w systemie Windows i mam konto Google, w szczególności TortoiseSVN i Google Code.

Po pierwsze, pełna integracja powłoki, aby zrobić wszystko w repozytorium (a dla ciebie, Linuksa, RabbitVCS robi to samo), nie potrzebujesz głównego GUI. Uzyskanie repozytorium jest łatwe jak pobranie, nie wymaga SSH (nie pamiętam, czy Github wymagał SSH do ściągania) i nie ma całego repo + wszystkie przeszłe zatwierdzenia siedzące na twoim HD.

Zatwierdzanie jest wyjątkowo łatwe, głównie dlatego, że nie jest wymagane SSH ani inscenizacja. Po prostu sprawdzasz wszystkie pliki, które chcesz, korzystając z bardzo pomocnej opcji zaznacz wszystko, która w mojej wersji msysgit nie była dostępna, wpisz komunikat zatwierdzenia i wciśnij zatwierdzenie. Następnie Google Code prosi o podanie danych logowania (które przechowują większość klientów) i dokonanych czynności. Prosty, łatwy i bez SSH

Numery wersji Za pomocą prostego kodu możesz dodać numer wersji i numer zatwierdzenia do wszystkich transakcji, co znacznie ułatwia sprawę. Otrzymasz również przydatne numery wersji, które faktycznie pokazują zmianę, np. 1.8.6.5165 jest nowszy niż 1.8.6.5164.

Dokumentacja? Trudno powiedzieć. Żółw jest udokumentowany, ale tak długo nie odwoływałem się do oficjalnej dokumentacji, że nie mogę ocenić. Wystarczyło mi przeczytanie prostego przewodnika wprowadzającego.

Scalanie jest czymś innym, czego nie mogę porównać. Musiałem to zrobić raz w Git, gdy ktoś inny dokonał zmiany w pliku, nad którym pracowałem, ale nigdy w SVN.


Który poleciłbym? W dużych zespołach git ma swoje zalety, głównie w nieliniowym cyklu rozwojowym. W innym projekcie widziałem, jak 4 programistów zaczynało w oddzielnych gałęziach, a następnie łączyło cały kod w bardzo dziwny sposób, który w jakiś sposób przekształcił się w końcową gałąź główną. Github i msysgit miały naprawdę fajne narzędzie do wizualizacji całego projektu, który naprawdę mi się podobał.

W przypadku projektów dla pojedynczego dewelopera lub małego zespołu SVN byłby najlepszy, ponieważ większość funkcji Gits nie jest używana, a Ty dostajesz tylko jej negatywne części. Prostota to taka miła rzecz

TheLQ
źródło
6
Połączenie z SVN jest dość ryzykowne (w porównaniu z git). To jedna rzecz, na którą należy zwrócić uwagę przy każdym porównaniu.
Khelben
5
Dlaczego za każdym razem „wychowujesz korowód”? To kluczowy agent. Wystarczy, że podniesiesz go tylko raz, gdy zalogujesz się na swoim komputerze. Dodajesz swój klucz i gotowe . (I możesz to jeszcze ułatwić, kojarząc plik klucza z widowiskiem i dodając go do folderu startowego. Zaloguj się, pojawi się okno dialogowe z monitem o podanie hasła.)
Frank Shearar,
3
@Thorbjoern @Frank Shearer: Myślę, że sam fakt, że mówisz „możesz to zrobić, możesz to zrobić i nie mieć tych problemów” podkreśla, że ​​są to rozwiązania problemu lub problemu. To nie jest problem z niektórymi innymi VCS.
Steven Evers,
4
Ta odpowiedź wydaje mi się bardzo narzekaniem i jękiem na coś, czego plakat najwyraźniej nie poświęcił czasu na zrozumienie. Spędziłem dużo czasu zarówno w git, jak i svn, zarówno na systemie Linux, jak i Windows, i zeznam, że git jest znacznie lepszy od svn, jeśli chodzi o koncepcję, model danych, zrozumiałość i użyteczność.
gahooa
4
@ TheLQ Nie. To wcale nie jest „mentalność Linuksa”. Jest to prosta rzecz do skonfigurowania, jest dobrze udokumentowana, PuTTY to doskonały pakiet aplikacji dla systemu Windows, który sprawia, że ​​korzystanie z niego jest naprawdę proste. Naprawdę powinieneś szyfrować przesyłany kod, jeśli pracujesz za pośrednictwem dowolnej sieci publicznej. Użytkownicy systemu Windows obrażają to, że są zbyt głupi, aby nauczyć się korzystać z narzędzi, z których powinni korzystać. Nie proszę ludzi, żeby się pociskali. Proszę o zaszyfrowanie ich ważnych informacji.
Frank Shearar,
22

Poniższy cytat z Q4TD podsumowuje to dla mnie:

„Kochałem Gita, dopóki go nie wypróbowałem. Teraz kocham Mercurial. ”

        - Tor Norbye, The Java Posse Podcast

Ponadto hgsubversion tworzy całkiem dobrego klienta subversion dla Linuksa (gdzie zwykle używam wiersza poleceń, w przeciwieństwie do systemu Windows, w którym zwykle używam TortoiseSVN). Największa zaleta: brak .svnpodfolderów w każdym folderze, tylko .hgna najwyższym poziomie.

Aktualizacja: W odpowiedzi na prośbę Alexa w komentarzach, aby „powiedzieć więcej o tym, dlaczego git nie działał dla ciebie i jak Mercurial działał lepiej”:

Nie powiedziałbym, że Git nie działa dla mnie, ale Murcurial działa lepiej IMO.

Krótko mówiąc, jest to Mercurial:

alternatywny tekst

a to jest Git:

alternatywny tekst

Zapewniam, że Mercurial zrobi wszystko, czego potrzebuje większość programistów, bez konieczności przeglądania instrukcji, aby dowiedzieć się, jak wykonywać codzienne czynności.

Wprawdzie używam Gita tylko sporadycznie, ale społeczność programistów gaga nad językami takimi jak Ruby i Python, po części ze względu na ich zwięzłość i elegancję, podczas gdy Git czuje się jak wielbłąd zaprojektowany przez komitet wielbłądów.

Bah, teraz spójrz na to, co zrobiłeś? Wszędzie panuje rozkaz. Idź dalej, nic do zobaczenia ... nic do zobaczenia ...

Aktualizacja 2: I kolejny tweet apropos, na który właśnie natknąłem się:

„Git staje się łatwiejszy, gdy zrozumiesz, że gałęzie są homeomorficznymi endofunkorami mapującymi podfoldery przestrzeni Hilberta”.

Evan
źródło
Czy kiedykolwiek próbowałeś RabbitVCS?
TheLQ
Nie, ale używam KDE, a nie Gnome, więc i tak by mi to nie pasowało. Od czasu do czasu będę korzystał z graficznego klienta SVN w systemie Linux, ale tylko tak naprawdę, robiąc coś nieco ezoterycznego, na przykład przeglądając repozytorium lub porównując poprzednie wersje. Nie dotyczy zwykłego dodawania / usuwania / zatwierdzania / rejestrowania. Linia poleceń jest szybsza.
Evan
2
Czy możesz powiedzieć więcej o tym, dlaczego git nie działał dla ciebie i jak Mercurial działał lepiej? To byłoby całkiem interesujące do przeczytania.
Alex Feinman,
Jestem prawie pewien, że w przedstawieniu Gita brakuje prostej brzytwy o długości 6 cali ...
Tim Post
2
@Tim: rebase? Prawdopodobnie jest po drugiej stronie.
Alan Pearce,
14

Nie mam ani jednego „najlepszego” systemu kontroli wersji, ale raczej jednego najlepszego paradygmatu VCS.

Użyłem wielu różnych scentralizowanych systemów kontroli wersji i wielu różnych rozproszonych systemów kontroli wersji. I mogę bez wahania powiedzieć, że nikt nigdy nie powinien narzucać sobie CVCS.

Nie obchodzi mnie, który DVCS wybierzesz (moim szczególnym faworytem jest Git), ale zrób sobie przysługę i skorzystaj z DVCS. Po pierwsze: będziesz znacznie bardziej elastyczny. DVCS mogą w prosty sposób emulować przepływ pracy CVCS (nigdy nie rozwidlaj repozytorium i traktuj swoje lokalne repozytoria tylko jako pamięć podręczną zamiast niezależnego rozwidlenia), podczas gdy odwrotność jest niemożliwa. I chociaż logicznie, wykonywanie tej emulacji powinno pociągać za sobą pewne koszty (i rzeczywiście tak jest), nadal uważam, że jest łatwiejsze w użyciu (nie wspominając o wiele bardziej wydajne z powodu lokalnego buforowania) niż którykolwiek z CVCS, których użyłem.

Jörg W Mittag
źródło
3
To świetna odpowiedź. Nie ma jednego „najlepszego” VCS, ale całkowicie się zgadzam, że należy używać DVCS.
Nick Hodges
Zrób kopalnię DVCS, ale proszę, trzymaj homeomorficzne endofunkcje mapujące podfoldery przestrzeni Hilberta, proszę. Ergo, Mercurial.
Warren P
11

Nie mogę powiedzieć, że napotkałem najlepsze oprogramowanie do kontroli wersji, ale mogę powiedzieć, abyś trzymał się z dala od VSS i MKS. Oba są psami, których należy unikać za wszelką cenę.

Walter
źródło
7

Nie powiedziałbym najlepiej, ale taki, który ma bardzo ciekawe funkcje i koncepcje.

Fossil to rozproszona kontrola wersji, śledzenie błędów i projekt wiki zbudowany na bazie SQLite jako repozytorium.

Maniero
źródło
5

Team Foundation Server

Dlatego:

  1. To dobry, solidny VCS . (Pod żadnym względem nie uważałbym tego za najlepsze, ale ma fajne dodatki.)
  2. Wbudowane śledzenie zadań i błędów zintegrowane z Visual Studio pomaga mi pozostać skupionym i wiedzieć, na czym muszę pracować w jednym miejscu (automatyczne stosowanie zameldowania do błędu lub zadania i zamykanie go jest całkiem dobre, chociaż możesz pobierz wtyczki do innych systemów / eclipse / etc.)
  3. Integruje zadania / śledzenie błędów / projekty bezpośrednio z serwerem Project Server, dlatego rzadko muszę aktualizować plany projektów lub karty czasu pracy. Aktualizacje projektu w Project Server automatycznie filtrują jako zadania do TFS i Visual Studio, aby automatycznie je zobaczyć.
Ryan Hayes
źródło
2
Jestem ciekawy, jak się czułeś, gdy Twój przepływ pracy został ograniczony do programu Visual Studio wyłącznie do wszystkich prac programistycznych. Czy musiałeś wykonać konfigurację infrastruktury TFS? Moje wrażenia były przeciwne do twoich w ten sposób: # 1 - VCS nie był łatwy w użyciu, często był niestabilny, a tryb offline został stworzony przez samego szatana. # 2 Wbudowane śledzenie zadań i błędów było uciążliwe w porównaniu z innymi narzędziami, więc # 3 było dla nas nieistotne i stworzyło zduplikowaną pracę. Używałem go 3 razy teraz z tymi samymi złymi wynikami za każdym razem.
Jordan
1. Zgadzam się z trybem ssania offline. Jednak nie miałem wielu problemów z Internetem, ale zawsze jestem podłączony. Wiele elementów sterujących VCS, szczególnie z mapowaniem folderów, jest faktycznie ukrytych głęboko w menu. Czy to masz problem? 2. Jest to zdecydowanie bardziej kłopotliwe, ale ogólnie oszczędza pracę zespołowi zintegrowanemu z serwerem Project. 3. W jaki sposób tworzy zduplikowaną pracę? Czy powielasz zadania na serwerze projektu i TFS? Dostępna jest wtyczka open source na rok 2007 i wersja beta na rok 2010, które pozwalają im synchronizować się ze sobą.
Ryan Hayes,
1
Ograniczało mnie to do VS, ale jesteśmy całkowicie sklepem .NET. Używam TFS z moimi projektami Java w domu. Wypróbuj SVNBridge na svnbridge.codeplex.com, który pozwala używać Tortoise z TFS. Jeśli używasz Tortoise (jak większość ludzi Javy, Ruby, nie -.net), to powinno ci pomóc w przepływie pracy w innych projektach.
Ryan Hayes,
4

W swojej długiej historii korzystałem z wielu systemów kontroli wersji:

  • RPPT - (Rolki perforowanej taśmy papierowej). W pudełku na buty. Nie żartuję.
  • PVCS - (system kontroli wersji Polytron). Pierwszy prawdziwy VCS, którego użyłem.
  • SCCS - tak dawno temu nie pamiętam nic wyjątkowo dobrego ani złego.
  • RCS - jak zauważyli inni, wolałby ssać spocone kulki osła.
  • CVS - był to tylko ból, gdy był używany z więcej niż 2 programistami. najlepsza funkcja: rcs2cvs.
  • VSS - działa, z wyjątkiem wtorków, kiedy psuje całe twoje repozytorium.
  • Perforce - kosztuje więcej niż mój samochód. Sam VCS jest do zaakceptowania, ale chuligani informatycy, którzy kontrolują każdy aspekt korzystania z niego, nigdy nie znajdą go na mojej „preferowanej” liście.
  • SVN - rozgałęzianie i łączenie jest suką, ale ogólnie jest lepsze niż którekolwiek z poprzednich. Nie tak dobrze z dużą ilością drobnych zaległych zmian oczekujących na recenzję.
  • Mercurial - lubię to małe doświadczenie. Mógłbym spróbować w moim następnym projekcie.
  • Git - nigdy nie miałem okazji z niego skorzystać.

Chociaż para była okropnością, większość z nich była „w porządku”. Nie przeszkadzali mi. Tak długo, jak narzędzie nie utrudnia mojego życia , nie mam nic przeciwko.

Prawdziwe jest zrozumienie mocnych i słabych stron każdego z nich. Zrozum środowisko docelowe:

  • rozproszone lub lokalne
  • mały zespół lub duży
  • hostowana usługa vcs, czy nie
  • łatwa integracja z innymi narzędziami

Joel wyszedł także z ważnym spostrzeżeniem: poznaj narzędzie i jego prawdziwy model użytkowania. Mocno walczył, próbując sprawić, by Mercurial zachowywał się jak Subversion.

brettmjohnson
źródło
1
Gdyby tylko komentarz na temat VSS był żartem ... unikaj jak zarazy.
DevSolo,
Ach, PVCS, wspomnienia, które przywracają :) Co to za śmieci.
Henry,
Ta lista przypominała mi oparte na języku „strzelanie sobie w stopę”. +1
Orbling
Pamiętam złe rzeczy o SCCS, ale ogólnie było to użyteczne. Pamiętam, jak próbowałem wykonywać jednoczesną pracę na plikach z SCCS i innymi programistami i dlatego zakochałem się w CVS, kiedy to zobaczyłem.
David Thornley,
Visual SourceSafe, A VCS szczególnie dla programistów, którzy chcą wydłubać oczy łyżkami.
Mark Booth
2

Jednym z nowszych systemów, z których korzystamy w moim biurze, jest Plastic SCM (http://www.plasticscm.com/). Działa bardzo dobrze dla naszego małego zespołu i daje nam świetną kontrolę nad każdym aspektem zarządzania źródłami.

Tom A.
źródło
1

SCCS .

Lub, jeśli nie mieszkasz w jaskini przez ostatnie 38 lat, CSSC .

Poważnie, moja firma używa TeamWare , który jest rodzajem pseudo DVCS opartym na SCCS.

Nie żartuję.

Firma Sun przestawiła się na mercurial z TeamWare zaledwie kilka lat temu. Teraz powinieneś zrozumieć, dlaczego Java wydaje się poruszać tak wolno.

Geoffrey Zheng
źródło
1

MPW: Cóż, tak naprawdę nie mogę dać opinii pomimo moich wysiłków.

To było w czasach, gdy uczyłem się programowania w szkole średniej, a jedynym naprawdę darmowym kompilatorem C ++ był Macintosh Programming Workbench, który trzymałem na dysku zip i wrzucałem do dowolnego programu Performa dostępnego w laboratorium.

MPW przyszedł z dziesiątkami narzędzi (z których żadne nie było edytowane, to było osobne pobieranie), a jednym z nich było narzędzie do kontroli wersji. Otworzyło się małe okno z pojedynczą linią tekstu, a ty miałeś przeciągnąć i upuścić na nim swoje projekty lub pliki. Nie miał żadnej dokumentacji, którą kiedykolwiek mogłem odkryć, co jest niezwykłe, biorąc pod uwagę, że wszystko inne wydawało się mieć świetne dokumenty, więc nigdy nie do końca wiedziałem, jak z niego korzystać.

To był mój pierwszy pędzel do VC i ostatni od dłuższego czasu. Teraz używam git do wszystkiego.

SingleNegationElimination
źródło
Rzutnik multimedialny! Podczas pracy w niepełnym wymiarze godzin na studiach użyłem (wyuczonej) wersji tego. Dobre czasy.
RyanWilcox,
0

RCS - System kontroli wersji

Łatwe kodowanie solo.

Jé Queue
źródło
Żartujesz, prawda Xepoch? Niech Bóg żartuje.
Marc W
Rozśmieszacie mnie. Właściwie używam RCS, ale TYLKO dla moich osobistych stron internetowych, i c. W połowie żartowałem z tego, że używam go do większego rozwoju, ALE widziałem, że jest on używany wyłącznie (a nie CVS) na współużytkowanych systemach uniksowych. Szczerze mówiąc, nie mieliśmy z tym żadnych problemów, ale NIE nadaje się do niczego poza funkcją jednego serwera.
Jé Queue,
1
@Xepoch, możesz lepiej nauczyć się Git lub Mercurial - DCVS świetnie sprawdza się w rozwoju solo.
Fishtoaster
1
Wiesz, co jest naprawdę miłe w RCS? Możesz umieścić wszystkie pliki RCS, v we właściwej strukturze katalogów, a repozytorium CVS jest prawie gotowe. Istnieje mnóstwo narzędzi do konwersji z CVS na dowolny nowoczesny system, który ci się podoba, taki jak Mercurial.
David Thornley,
@Xepoch, łatwość tworzenia kopii zapasowych rozproszonych plików vcs jest nie do pobicia.
0

Nie ClearCase, przynajmniej dla systemu Unix / Linux (być może w systemie Windows instalator jest łatwiejszy). Łatwiej było mi nauczyć się nowego narzędzia, Perforce, niż aktualizować nasz serwer ClearCase.

Obecnie używam Perforce w pracy i to mi się podoba, ale nie mam pojęcia, czy to jest najlepsze. Konfigurowanie środowiska wiersza poleceń i serwera Perforce Server jest nieco niewygodne, ale korzystanie z programu Visual Client jest dość łatwe. Lubię myśleć, że użytkownicy mają dość łatwy czas na codzienne zadania; to tylko wstępna konfiguracja wymaga trochę pracy.

Szansa
źródło
0

Użyłem Visual SourceSafe i nienawidziłem go, ale było lepsze niż nic, ale niewiele. Przez ostatnie kilka lat korzystał z czegoś o nazwie QCVS firmy Qumasoft.com napisanego, będącego własnością i wspieranego przez programistę Jima Vorisa. Proste GUI, niska cena, dobre wsparcie.

Po prostu działa.

Crosenblum
źródło