Co SVN robi lepiej niż Git? [Zamknięte]

Nie ma wątpliwości, że większość debat na temat narzędzi programistycznych koncentruje się na osobistym wyborze (przez użytkownika) lub na nacisku na projekt , to znaczy na optymalizację projektu pod kątem konkretnych zastosowań (przez konstruktora narzędzi). Edytory tekstu są prawdopodobnie najbardziej znanym przykładem - koder, który pracuje w systemie Windows w pracy i kodów w Haskell na Mac w domu, wartości cross-platform i integracji kompilator i tak wybiera Emacs ponad TextMate itp

Rzadziej zdarza się, że nowo wprowadzona technologia jest autentycznie, wyraźnie lepsza od istniejących opcji.

Czy tak jest w przypadku systemów kontroli wersji (VCS), w szczególności scentralizowanego VCS ( CVS i SVN ) w porównaniu do rozproszonego VCS ( Git i Mercurial )?

Używam SVN przez około pięć lat, a SVN jest obecnie używany tam, gdzie pracuję. Niecałe trzy lata temu przerzuciłem się na Git (i GitHub) dla wszystkich moich osobistych projektów.

Mogę wymyślić szereg zalet Git nad Subversion (i które w większości są abstrakcyjne w stosunku do zalet rozproszonych w scentralizowanym VCS), ale nie mogę wymyślić jednego przeciwnego przykładu - jakiegoś zadania (to jest istotne i pojawia się u zwykłych programistów) workflow), że Subversion radzi sobie lepiej niż Git.

Tylko konkluzja mam wyciągnąć z tego jest to, że nie mam żadnych danych - nie że Git jest lepszy, etc.

Domyślam się, że istnieją takie kontrprzykłady, stąd pytanie.

Subversion to centralne repozytorium

Chociaż wiele osób będzie chciało mieć rozproszone repozytoria z oczywistymi korzyściami związanymi z szybkością i wieloma kopiami, są sytuacje, w których centralne repozytorium jest bardziej pożądane. Na przykład, jeśli masz jakiś krytyczny fragment kodu, do którego nie chcesz, aby ktokolwiek miał do niego dostęp, prawdopodobnie nie chciałbyś umieścić go w Git. Wiele korporacji chce utrzymać scentralizowany kod, a (jak sądzę) wszystkie (poważne) projekty rządowe znajdują się w centralnych repozytoriach.

Subwersja jest konwencjonalną mądrością

To znaczy, że wiele osób (zwłaszcza menedżerów i szefów) ma zwykły sposób na numerowanie wersji i postrzeganie rozwoju jako „pojedynczej linii” z czasem zakodowanej w mózgu. Bez obrazy, ale swoboda Gita nie jest łatwa do przełknięcia. Pierwszy rozdział każdej książki Git mówi o tym, aby usunąć z umysłu wszystkie konwencjonalne ideały i zacząć od nowa.

Subversion robi to w jedną stronę i nic więcej

SVN to system kontroli wersji. Ma jeden sposób na wykonanie swojej pracy i wszyscy robią to w ten sam sposób. Kropka. Ułatwia to przejście do / z SVN z / do innego scentralizowanego VCS. Git NIE jest nawet czystym VCS - to system plików, ma wiele topologii konfigurowania repozytoriów w różnych sytuacjach - i nie ma żadnego standardu. To sprawia, że ​​trudniej jest wybrać jeden.

Inne zalety to:

• SVN obsługuje puste katalogi
• SVN ma lepszą obsługę Windows
• SVN może sprawdzać / klonować poddrzewa
• SVN obsługuje wyłączną kontrolę dostępu, svn lockktóra jest przydatna w przypadku trudnych do scalenia plików
• SVN obsługuje pliki binarne i duże pliki łatwiej (i nie wymaga kopiowania starych wersji wszędzie).
• Dodanie zatwierdzenia wymaga znacznie mniej kroków, ponieważ nie ma żadnego ściągania / wypychania, a lokalne zmiany są zawsze domyślnie bazowane svn update.

Jedną zaletą Subversion w porównaniu z Git może być to, że Subversion pozwala sprawdzać tylko poddrzewa. Dzięki Git całe repozytorium jest jednostką, możesz uzyskać tylko wszystko lub nic. Dzięki kodowi modułowemu może to być całkiem miłe w porównaniu do submodułów Git. (Oczywiście podmoduły Gita też mają swoje miejsce).

I mała drobna korzyść: Subversion może śledzić puste katalogi. Git śledzi zawartość pliku, więc katalog bez pliku nie pojawi się.

Mogę wymyślić trzy. Po pierwsze, grokowanie jest nieco łatwiejsze, szczególnie dla programistów. Pod względem koncepcyjnym jest to znacznie prostsze niż opcje DCVS . Drugi to dojrzałość, szczególnie TortoiseSVN w systemie Windows. TortoiseHg szybko nadrabia zaległości. Po trzecie, natura bestii - po prostu obraz systemu plików, w którym można sprawdzić rzeczy z dowolnego poziomu drzewa - może się przydać w niektórych scenariuszach - na przykład w wersjach różnych plików konfiguracyjnych w wielu różnych miejscach serwerów bez dziesiątek repozytoriów.

Nie oznacza to, że nie przenosimy całego rozwoju do Mercurial.

• Repozytoria SVN są łatwiejsze do zarządzania z punktu widzenia menedżera i administratora ( ACL + metody uwierzytelniania + hotcopy + kopie lustrzane + zrzuty)
• Haki SVN * są łatwiejsze do wdrożenia i obsługi
• svn:external ma większą moc i elastyczność niż submoduły
• Drzewa repozytoriów oparte na systemie plików są łatwiejsze w użyciu niż repozytoria monolityczne z separacją tylko logiczną
• SVN ma więcej różnych narzędzi klienckich
• SVN ma zewnętrzne interfejsy internetowe innych firm, znacznie lepsze niż Git
• SVN nie łamie ci mózgu

Napisałem to jako komentarz do odpowiedzi kogoś innego, ale myślę, że zasługuje na to, aby być odpowiedzią samą w sobie.

Starannie wybrana konfiguracja SVN mojej firmy wymaga blokowania na poziomie plików w celu edycji treści i nigdy nie używa scalania. W rezultacie wielu programistów walczy o blokady, co może być poważnym wąskim gardłem i nigdy nie ma szans na konflikt scalania.

SVN zdecydowanie lepiej kontroluje zarządzanie odgórne niż Git. Podczas migracji Skunkworks do Git (prosząc o wybaczenie, a nie o pozwolenie) wiele razy przerażałem mojego menedżera, że ​​nie ma żadnego centralnego głównego serwera kontrolującego, który byłby wspierany programowo, na którym wszyscy jesteśmy niewolnikami.

Moje powody:

• dojrzałość - zarówno serwer, jak i narzędzia (np. TortoiseSVN)
• prostota - mniej kroków, zatwierdzenie jest zatwierdzeniem. DVCS, takie jak Git i Mercurial, wymagają zatwierdzenia, a następnie wypchnięcia.
• obsługa binarna - SVN obsługuje binarne pliki wykonywalne i obrazy lepiej niż Git / Hg. Szczególnie przydatne w projektach .NET, ponieważ lubię sprawdzać narzędzia związane z kompilacją w celu kontroli źródła.
• numeracja - SVN ma czytelny schemat numeracji zatwierdzeń, wykorzystujący tylko cyfry - łatwiejsze do śledzenia numery wersji. Git i Hg robią to zupełnie inaczej.

Doceniam to, że szukasz dobrych informacji, ale tego rodzaju pytanie po prostu zachęca: „Myślę, że Git to tak wiele wygranych i svn teh suxorz!” odpowiedzi

Próbowałem i osobiście znalazłem Gita trochę za dużo dla mojego małego zespołu. Wydawało się, że byłoby świetnie dla dużego rozproszonego zespołu lub grupy zespołów rozproszonych geograficznie. Rozumiem w pełni zalety Git, ale moim zdaniem kontrola źródła nie jest czymś, co utrzymuje mnie w nocy.

Jestem łowcą jeleni, a kiedy ja i moi przyjaciele wychodzimy, są uzbrojeni po zęby, najeżeni amunicją i zaawansowanym technologicznie sprzętem. Pojawiam się z jednym karabinem, siedmioma kulami i nożem. Jeśli potrzebuję więcej niż siedem rund, robię coś złego i robię tak dobrze, jak wszyscy inni.

Chodzi mi o to, że jeśli jesteś małym zespołem pracującym nad średnim lub małym projektem i znasz już SVN, użyj go. Jest to z pewnością lepsze niż CVS lub (dreszcz) SourceSafe i nie zajmuje mi więcej niż pięć minut, aby skonfigurować repozytorium. Git może czasami być przesadny.

To wszystko jest względne i, jak powiedział maple_shaft, jeśli jeden działa dla ciebie, nie zmieniaj się!

Ale jeśli naprawdę czegoś chcesz , powiedziałbym, że może lepiej dla projektantów, programistów internetowych i tym podobnych - lepiej radzi sobie z obrazami i plikami binarnymi .

Użyteczność To nie jest tak naprawdę zasługa Subversion, ale raczej TortoiseSVN .. TortoiseGit istnieje, ale wciąż jest wiele do zrobienia, aby dopasować TortoiseSVN.

Gdybyś zapytał, co Git robi lepiej niż SVN, odpowiedziałbym GitHub . To zabawne, jak narzędzia innych firm robią tak ogromną różnicę.

Kiedy nie musisz rozgałęziać się i łączyć , SVN (z TortoiseSVN w systemie Windows) jest bardzo łatwy do zrozumienia i użycia. Git jest zbyt skomplikowany w prostych przypadkach, ponieważ stara się ułatwić rozgałęzianie / scalanie.

(Wiele małych projektów nigdy nie musi rozgałęziać się, jeśli są dobrze zarządzane. Git jest ukierunkowany na złożone przypadki; dlatego większość dokumentacji Git zakłada, że ​​musisz wykonywać złożone operacje, takie jak rozgałęzianie i łączenie).

Mój dziadek mógł używać SVN na swoim komputerze z Windows XP, ale miałby problemy z używaniem Gita. Być może jest to bardziej osiągnięcie TortoiseSVN w stosunku do TortoiseGit , ale myślę, że jest to raczej związane z faktem, że Git jest z natury silniejszy, a zatem bardziej złożony, i nie ma sensu zrzucać go na ten sam poziom.

Teraz to naprawdę nie ma znaczenia dla mojego dziadka, ponieważ ostatnio nie programował. Byłem jednak kiedyś w zespole, w którym nasi graficy również używali kontroli źródła.

Są to ludzie, którzy po prostu oczekują, że ich narzędzia będą działać (ja też, ale mam realistyczną szansę, aby zmusić je do pracy w przypadku awarii) i będą intuicyjne. Poza tym, że sprowadzenie ich na DVCS byłoby dość dużym wysiłkiem , niewiele można było zyskać. A mając tylko dwóch programistów w zespole, sensownym było dla nas, abyśmy trzymali się SVN.

W pracy nie mogłem zmienić programistów z SVN na DVCS z dwóch powodów:

• Częściowe pobranie (jak tylko trzy foldery z różnych głębokości w drzewie projektu)
• Blokowanie plików (raporty w formacie binarnym)

• Poczucie bezpieczeństwa podczas wykonywania „svn commit”. Ponieważ zatwierdzenia trafiają na serwer, nie mogę zrobić żadnej pomyłki, która wymazałaby moje zmiany po ich zatwierdzeniu. W git, zatwierdzenia są lokalne, więc dopóki nie pcham, zbłąkane 'rm -rf' i wszystko się kończy.
• Zatwierdzenia są uwierzytelniane. Domyślnie w git mogę powiedzieć, że popełniam jak każdy.
• Mniej poleceń do nauki na co dzień. „svn checkout”, „svn up” i „svn commit” doprowadzą cię dość daleko.
• Wspólne kasy działają o wiele ładniej. Kiedy idziesz do zatwierdzenia, prosi cię o podanie nazwy użytkownika / hasła, nie musisz pamiętać o przekazaniu pewnych argumentów wiersza poleceń. Czasami w pracy mamy wspólną maszynę ze wspólną kasą svn jakiegoś projektu. Ktoś może powiedzieć „Bob, czy możesz na to patrzeć na tym komputerze” i może, i może zatwierdzić zmiany jako użytkownik bez żadnych wpadek.
• Układ repozytorium. Możesz mieć projekt parasolowy i podprojekty i wybrać, co sprawdzić, kiedy.
• Numery wersji są liczbami całkowitymi.
• Zaprojektowany do pracy z centralnym repozytorium.

Inne osoby opublikowały całkiem dobre odpowiedzi, ale co z uprawnieniami? Korzystając z Subversion przez SSH, możesz utworzyć osobne konto na swoim serwerze dla SVN. Różni programiści mogą mieć różny dostęp do różnych części repozytorium. Czy GIT może to zrobić? Wydaje mi się, że jest gitolit, ale po prostu nie wydaje mi się on tak elastyczny ani wytrzymały, ani nie znam nikogo, kto go rzeczywiście używa.

Prędkość. Czasami klonowanie dużego repozytorium git zajmuje 10 lub 15 minut, a repozytorium podobnej wielkości subversion zajmuje kilka minut.

Publikuję to jako odpowiedź, a nie komentarz.

Przyznaję, że DVCS są obecnie w modzie, ale postaram się wyjaśnić, dlaczego.

DVCS są lepsze, ponieważ tak jak wiele osób mówiło: „tak powinniśmy pracować od samego początku”. To prawda, że ​​możesz zrobić z DVCS to, co kiedyś z SVN, więc w taki sposób, że SVN staje się przestarzały.

Jednak nie każdy projekt oprogramowania jest tak dobry, jak to możliwe:

• W projekcie długoterminowym wiele zyskało na DVCS, ponieważ zużywa mniej kosztów ogólnych, pozwala na znacznie lepsze zarządzanie (rozgałęzianie itp.) I jest bardzo obsługiwany przez hosty takie jak kod Google i github.

• Te projekty nie są jedynymi, istnieją inne rodzaje projektów, które są opracowywane w firmach bez żadnej pomocy ze strony świata zewnętrznego lub Internetu: wszystko odbywa się wewnętrznie i często krótkoterminowo. Dobry przykład: gra wideo. Kod ewoluuje szybko.

W tym drugim przypadku programiści nie potrzebują rozgałęzień ani wyrafinowanych funkcji, które może zaoferować DVCS, chcą jedynie udostępnić kod źródłowy i zasoby. Tworzony przez nich kod prawdopodobnie nie zostanie ponownie użyty, ponieważ jest określony termin. Opierają się raczej na SVN niż na DVCS z kilku powodów:

• Deweloperzy mają maszyny należące do firmy, co może się szybko zmienić. Konfiguracja repo to strata czasu.
• Jeśli ci faceci nie mają własnej maszyny, jest mniej prawdopodobne, że będą pracować nad tym samym kodem źródłowym / częścią projektu. Plus jeden za scentralizowane dane.
• prędkości sieci i duże pieniądze pozwalają na korzystanie ze scentralizowanego serwera, który zajmuje się wszystkim SVN, to zła praktyka, ale tworzone są kopie zapasowe itp.
• SVN jest po prostu prostszy w użyciu, nawet jeśli jest to niewłaściwy sposób: synchronizacja plików na urządzeniach równorzędnych bez nadmiarowości nie jest prostym problemem, a „zrób to we właściwy sposób” po prostu nie może zrobić tego na czas, jeśli zawsze chcesz, aby był doskonały.

Pomyśl o maszynie przemysłu gier i o tym, jak SVN oszczędza czas; ludzie komunikują się znacznie więcej na temat tych projektów, ponieważ gry polegają na powtarzalnym programowaniu i adaptacyjnym kodzie: nie ma nic trudnego do kodowania, ale należy to zrobić jak najszybciej. Programiści są zatrudniani, kodują swoją część, kompilują ją, testują trochę, zatwierdzają, wykonują, testerzy gier zajmą się resztą.

DVCS są tworzone dla Internetu i dla bardzo skomplikowanych projektów. SVN są przeznaczone dla małych, krótkoterminowych, zwartych projektów zespołowych. Nie musisz się dużo uczyć od SVN, to prawie FTP z głupim diffem.

Zarówno Subversion, jak i Git zachęcają do szczególnego (i bardzo odmiennego) podejścia do rozwoju i współpracy. Niektóre organizacje czerpią więcej z Git, a inne czerpią więcej z Subversion, w zależności od ich organizacji i kultury.

Git i Mercurial są doskonałe dla rozproszonych i luźno zorganizowanych zespołów wysoce kompetentnych profesjonalnych programistów. Oba te popularne narzędzia DVCS zachęcają do małych repozytoriów, a ponowne użycie między programistami odbywa się za pośrednictwem opublikowanych bibliotek z (względnie) stabilnymi interfejsami.

Z drugiej strony Subversion zachęca do bardziej scentralizowanej i ściśle powiązanej struktury zarządzania, z większą komunikacją między programistami i większym stopniem kontroli organizacyjnej nad codziennymi działaniami programistycznymi. W tych bardziej zwięzle zorganizowanych zespołach ponowne wykorzystanie między programistami odbywa się zwykle za pośrednictwem niepublikowanych bibliotek z (względnie) niestabilnymi interfejsami. TortoiseSVN pozwala również Subversion na wspieranie multidyscyplinarnych zespołów z członkami, którzy nie są profesjonalnymi programistami (np. Inżynierami systemów, inżynierami algorytmów lub innymi specjalistami z danej dziedziny).

Jeśli Twój zespół jest rozproszony, a członkowie pracują z domu lub z wielu różnych międzynarodowych witryn, lub jeśli wolą pracować samotnie i w ciszy, przy niewielkiej komunikacji osobistej, wówczas DVCS, takie jak Git lub Mercurial, będzie dobrym rozwiązaniem dopasowanie kulturowe.

Z drugiej strony, jeśli Twój zespół znajduje się na jednej stronie, z aktywnym podejściem zespołowym do rozwoju i dużą ilością bezpośredniej komunikacji z „szumem” w powietrzu, SVN może być lepsze dopasowanie kulturowe, szczególnie jeśli masz wiele zespołów interdyscyplinarnych.

Oczywiście możliwe jest skonfigurowanie Git i Hg (tak potężnych i elastycznych, jak są), aby robiły prawie wszystko, co chcesz, ale jest to zdecydowanie więcej pracy i są zdecydowanie trudniejsze w użyciu, szczególnie dla tych członków zespołu, którzy w naturalny sposób nie byłby skłonny do korzystania z jakiejkolwiek formy kontroli wersji.

Wreszcie stwierdzam również, że funkcja udostępniania za pomocą „gorącego” rozwoju biblioteki pod Svn (z CI i podejściem testowym) pozwala na tempo skoordynowanego rozwoju, które jest trudne do osiągnięcia przy bardziej rozproszonym i luźno powiązanym zespole.

Poniżej znajdują się dwa powody, dla których nadal jestem w SVN.

1. Krzywa uczenia się. SVN jest łatwiejszy niż Git, nawet konfiguracja (serwer lub klient), użyteczność i polecenia.
2. Lepsze pakiety serwerów, takie jak Subversion Edge , VisualSVN , uberSVN itp.

Istnieją obecnie dwa główne trendy w kontroli wersji; Dystrybucja i integracja .

Git jest świetny w decentralizacji.

SVN ma wiele narzędzi, które można z nim zintegrować. Często konfiguruje się serwer SVN, aby podczas wpisywania poprawki wspomniał o numerze błędu w komentarzu do meldowania, i ustawia go automatycznie na stan „w trakcie testowania” i powiadamia przypisanego testera, że ​​musi Spójrz na to. Następnie możesz oznaczyć wydanie i uzyskać listę wszystkich błędów naprawionych w tym wydaniu.

Narzędzia, które robią to z SVN, są dojrzałe i są używane każdego dnia.

W Subversion możesz edytować komunikaty dziennika (zwane również „komunikatami zatwierdzenia”) po zakończeniu zatwierdzenia i wypchnięciu. W przypadku większości praktycznych zastosowań jest to niemożliwe z założenia w zdecentralizowanych systemach, w tym git. Oczywiście w git możesz zrobić polecenie „git commit --amend”, ale to nie pomoże ci po wypchnięciu twojego zatwierdzenia gdzie indziej. W SVN, gdy edytujesz komunikat dziennika, robisz to w centralnym repozytorium, które wszyscy współużytkują, więc wszyscy otrzymają edycję i bez zmiany identyfikatora zmiany.

Edytowanie komunikatów dziennika po fakcie jest często bardzo przydatne. Oprócz zwykłego naprawienia błędu lub pominięcia w komunikacie dziennika, umożliwia on między innymi aktualizację komunikatu dziennika w celu odniesienia do przyszłego zatwierdzenia (takiego jak poprawka, która naprawia błąd lub kończy prace wprowadzone w bieżącej wersji) .

Nawiasem mówiąc, nie ma niebezpieczeństwa utraty informacji. Haczyki przed zmianą i po zmianie mogą zapisać historię starych wiadomości, jeśli naprawdę się martwisz, lub wysłać e-mail z różnicą w dzienniku (w rzeczywistości jest to bardziej powszechne), dzięki czemu istnieje ścieżka audytu.