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

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?

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.

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.

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

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:

a to jest Git:

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”.

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.

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ę.

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.

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ć.

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.

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.

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.

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.

RCS - System kontroli wersji

Łatwe kodowanie solo.

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.

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.