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

293

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.

doug
źródło
3
@jokoon: Wydajny pod względem czego? Na pewno nie szybkość, ponieważ nawet szybki Ethernet jest wolny w porównaniu do operacji lokalnych.
maaartinus
4
Zawsze myślałem, że Git był bardzo ceniony. To moda, a programiści nie są odporni na mody - pomimo wielu sprzeciwów wobec tej myśli. Jak wszyscy na tym świecie, wszyscy chcą nowej błyszczącej zabawki (Git). Git może być dobry - lub nawet świetny dla niektórych osób - ale nigdy nie był lepszy niż SVN, gdy myślisz obiektywnie.
kupił777
3
Myślałem, że SVN jest nadal dobry w użyciu, krzywa uczenia się jest dobra, a następnie GIT.
Cheung,
5
Pytanie to zostało ostatnio zawieszone jako oparte głównie na opiniach. Ta klasyfikacja jest błędna; zauważ, że pytanie było otwarte przez długi czas; że istnieje wiele pytań na temat zalet DVCS i że pytanie nie pyta, czy jest lepsze (opinia), ale co robi lepiej. Różnice nie dotyczą opinii, ale tego, czy ogólny produkt jest - to trudne (ale nie o to chodzi w tym pytaniu).
Eamon Nerbonne,

Odpowiedzi:

207

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.
treecoder
źródło
55
„Subversion robi to w jeden sposób” - tak też myślałem, dopóki nie zacząłem swojej obecnej pracy. W mojej obecnej pracy mój szef, który twierdzi, że nie ma problemów z zaufaniem, skonfigurował serwer tak, aby wymagał blokowania. W naszym systemie nie występuje scalanie. Pliki są zablokowane w repozytorium i nikt inny nie może ich zapisać bez blokady. Kontrola odgórna, dla tych, których konstytucje tego wymagają, jest zdecydowanie czymś, co svn robi lepiej niż git.
Dan Ray
14
Jedną z zalet centralnego repozytorium jest łatwość tworzenia kopii zapasowych. Jeśli cały wpisany kod znajduje się w jednym miejscu, a to jedno miejsce ma kopię zapasową poza witryną, nie stracisz wszystkiego, jeśli Twoje biuro spłonie. W przypadku DVCS, chyba że wykonujesz kopie zapasowe maszyn programisty poza witryną, tracisz wszystko, co nie zostało wypchnięte na serwer, którego kopie zapasowe wykonano poza witryną.
Paul Tomblin
94
Dlaczego git nie może być używany w sposób scentralizowany? Posiadaj tylko jedno centralne repozytorium, a twoi deweloperzy mogą klonować, ciągnąć i pchać, tak jak kasują, aktualizują i zatwierdzają.
David Thornley,
29
@PaulTomblin - W zależności od przepływu pracy Git może zapewnić lepsze kopie zapasowe. Na przykład używamy prywatnych repozytoriów github i często wypycham swój kod do gałęzi funkcji. Jeśli zrobią to moi współpracownicy git fetch origin, każdy z nich ma kopię zapasową mojego kodu wraz z wszelką kopią zapasową, którą zapewnia sam Github. (Regularnie przycinamy scalone oddziały, zarówno lokalnie, jak i na Github.)
Nathan Long
52
Wydaje się, że sugerujesz, że centrala jest bezpieczniejsza dla dużych firm lub pracy rządowej. To po prostu nieprawda. Jeśli masz kopię kodu na swoim komputerze, masz kopię tego kodu. Nie ma znaczenia, czy pochodzi z centralnego serwera czy centralnego systemu plików z repozytorium DVCS.
John Fisher
131

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

Johnny
źródło
11
Praca z poddrzewami jest IMHO, jedyną rzeczą, którą SVN ma w stosunku do GIT. Punkt, puste katalogi są ładne, ale też nie są konieczne (i można je obejść). Gdyby podmoduły git i poddrzewo git były mniej mylące, wiele osób nie powstrzymałoby migracji od GIT. Inne zalety niektórych osób sprowadzają się do mentalności (programisty). Np. Jeśli potrzebujesz od góry do dołu, w porządku. Ale nie miałbym dla ciebie żadnej pracy.
Do
3
To zabawne, że są to jedyne rodzaje rzeczy, które można argumentować na korzyść SVN (i innej scentralizowanej kontroli wersji)
dukeofgaming,
1
Dlaczego to jest śmieszne? - Nowsze systemy uczą się na starszych systemach. Zaletą RCS jest nawet to, że git: pliki historii można łatwo edytować ręcznie i można mieć gałęzie dla poszczególnych plików. Ale eolution wiąże się z utratą funkcji ...
John
3
Słyszałem o firmie gier, która używa SVN zamiast GIT właśnie z tego powodu - kiedy mówisz o repozytorium o wielkości wielu GB, nagle staje się to ważne!
James
18
Począwszy od gita w wersji 1.8.0, możesz teraz użyć git subtreepolecenia, aby to zrobić dokładnie. Ostatnia zaleta subversion gryzie kurz :) Szczegóły tutaj: github.com/gitster/git/blob/… Uwaga: Mimo że jest to link do projektu github, git-subtree jest teraz częścią podstawowej dystrybucji git.
Carl
51

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.

Peter Mortensen
źródło
25
Ważniejszą zaletą jest łatwiejszy w użyciu, ponieważ zwiększa to prawdopodobieństwo użycia. SVN jest z pewnością znacznie lepszy niż brak kontroli wersji, a jeśli ktoś upiera się przy starych metodach, być może SVN jest najlepszym wyborem dla nich.
jhocking 30.09.11
12
@jhocking: Nie kocham SVN, ale jeśli ktoś powie mi: „Nie lubię tych nowych DVCS, więc zostanę przy CVS”, to zdecydowanie polecam: to łatwa droga do przynajmniej częściowo rozsądny VCS ;-)
Joachim Sauer
4
@jhocking Nowe sposoby nie zawsze są najlepsze w każdych okolicznościach. Przywołuje na myśl starą historię o tym, że NASA wydaje miliony dolarów na opracowanie pióra, które może pisać w gramaturze 0g. Kosmonauci natomiast zrobili z ołówków. Czasami stare sposoby są lepsze, TERAZ ZACZNIJ MOJEGO PRAWA!
wałek klonowy
25
@maple_shaft, a czasem nie są. snopes.com/business/genius/spacepen.asp
Peter Taylor
3
Łatwe w użyciu jest wysoce subiektywne i opiera się w dużej mierze na tym, jak próbujesz dopasować nową wiedzę do tego, co już wiesz. To także robi dużą różnicę, jakie jest twoje źródło nauki. Jeśli przeglądasz strony podręcznika, powodzenia. Jeśli uczy cię dobry nauczyciel, który już je szlifuje, masz to zrobione. Odkryłem, że git miał ogromny sens po obejrzeniu kilku dobrych filmów na YouTube. Jeśli zrozumienie uzyskasz od kogoś, kto już go przedestylował, do prostego rdzenia, wszystko będzie łatwiejsze do zrozumienia.
WarrenT
32
  • 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
Leniwy borsuk
źródło
23
Nie łamie ci mózgu? Chcesz nauczyć mnie, jak łatwo łączyć gałęzie z konfliktami w SVN?
WarrenT
4
„Lepsze” narzędzia / interfejsy, to ruchomy cel. Narzędzia poprawiają się po obu stronach. Nikt z nas nie wie, jakie narzędzia będą dostępne za kilka lat. Ta ocena 10 miesięcy temu może z czasem ulec zmianie, a teraz może być nieaktualna. Wolałbym zobaczyć merytoryczne odpowiedzi.
WarrenT
6
Konflikty drzew? Czek. Tak czy nie dla wszystkich opcji? Nie. Svn ma na celu rozwścieczyć. Czyste polecenie kopii roboczej? Nie. Cofnij nie może wyczyścić niewersjonowanych plików.
Warren P
1
Usunięcie wszystkiego i ponowne sprawdzenie spowoduje wyczyszczenie niewersjonowanych plików.
jgmjgm
Uwielbiam twój ostatni pomysł, Git złamał mi mózg: „(
Łukasz
24

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.

Dan Ray
źródło
Centralność jest kwestią mitu, a nie faktu. Nikt mnie nie powstrzyma przed zmianą. Dzięki cvcs mogą mnie powstrzymać od centralnej zmiany czegoś. To samo w dvcs. Słowo commit w cvcs konflates commit i push.
Warren P
@JathanathanHenson: to zdecydowanie nie jedyny powód, dla którego Torvalds nienawidzi SVN. SVN może być scentralizowany i może być lepszym CVS, ale to nie czyni go dobrym oprogramowaniem. Torvalds nienawidzi CVS / SVN nie dlatego, że są scentralizowane, ale dlatego, że uważa, że ​​są żałośnie złym oprogramowaniem. To, czy ma rację, czy nie, zależy od ciebie, ale zobaczysz ogromny sukces zarówno Linuksa (i Androida) - działającego na miliardach urządzeń - jak i Gita - który niemal podbija świat szturmem - ja. Pomyśl dwa razy, zanim się z nim nie zgodzisz. Wykład Torvaldsa wygłoszony w Google na Git przed laty jest niesamowity.
Cedric Martin
lol. Twój menedżer ma rację, że się boi, że nie ma odpowiedniego systemu tworzenia kopii zapasowych. Samo powiedzenie „ale to DVCS, więc ktoś będzie miał kopię” nie leci - wiem, kiedy zobaczyłem git używany na moim ostatnim miejscu, dosłownie nie miał żadnych kopii niektórych repozytoriów. Pamiętaj, że blokowanie może być dobre w niektórych sytuacjach i git zawodzi pod tym względem - chyba że masz magiczne narzędzie do scalania obrazów lub innych plików binarnych. git naprawdę działa tylko dla plików tekstowych.
gbjbaanb
22

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.
Grant Palin
źródło
1
„zatwierdzanie schematu numerowania” jest możliwe tylko wtedy, gdy masz kanoniczne pnie. W przeciwnym razie, który otrzyma główną numerację?
1
+1 odrętwienie w svn. Ten numer jest unikalny. istnieją narzędzia do używania tego numeru jako części numeru wersji aplikacji xx.yy.zz.12882, gdzie 12882 to numer wersji svn. Jeśli występuje problem z produkcją, możesz zapytać o numer wersji i masz dokładną wersję svn, w której oprogramowanie zostało zbudowane
k3b
22

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.

wałek klonowy
źródło
3
Naprawdę? W takim razie sugeruję, abyś spojrzał na skamielinę .
Spencer Rathbun
7
nie alarmujmy przy najmniejszej możliwej kontrowersji. Ważne tematy są często najbardziej kontrowersyjne i najprawdopodobniej wywołują mocno podtrzymane poglądy. Tak więc „tego rodzaju pytanie” jest ważne, a możliwość odpowiedzi poza zakresem nie jest prawdopodobna, aby go nie opublikować. Zakładam, że użytkownicy tej witryny to osoby dorosłe. Co więcej, sposób, w jaki moje Q zostało sformułowane, był, jeśli nie neutralny, wówczas pełen szacunku dla ludzi wywrotowych - odpowiedzi na moje Q będą musiały recytować przewagę subwersji nad gitem, a nie na odwrót.
doug
@SpencerRathbun, Thanks! Będę musiał na to rzucić okiem. Nie tyle kocham SVN, ile nie lubię GIT.
wałek klonowy
10
@Spencer - Przeciwnie, jako użytkownik obu, giti hgsugerowałbym mercurial dla każdego, kto uważa, że gitto za dużo. TortoiseHG byłby bardzo znany każdemu, kto używał TortoiseSVN (ma nawet te same nakładki Eksploratora w systemie Windows). Jest to z pewnością o wiele łatwiejsze niż VSS i byłbym zaskoczony, gdyby skonfigurowanie repozytorium hg zajęło więcej niż kilka sekund, zatwierdzenie stanu początkowego i sklonowanie go na dysku udostępnionym.
Mark Booth
@MarkBooth Jak stwierdzono w pierwotnym pytaniu, myślę, że jest to kwestia potrzeb i potrzeb. W moim obecnym miejscu pracy nie było repozytorium, zanim tam dotarłem. Potrzebowałem czegoś, co zawierało wszystkie lub większość narzędzi projektowych, które chciałem zebrać razem, było łatwe w użyciu, zachowywało wszystko zamiast delt i działało dla zespołów 1 lub 2 osób na wielu komputerach.
Spencer Rathbun
20

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 .

Wieża
źródło
2
Jak SVN radzi sobie z nimi lepiej? Git uważa każdy plik za BLOB.
WarrenT
4
@WarrenT ze względu na przepływy pracy, z git dużo się rozgałęziasz i scalasz (lub po co męczyć się z jego użyciem) i po prostu nie możesz realistycznie scalić plików binarnych. Dlatego często umieszczasz właściwość „potrzebuje blokady” na plikach binarnych w SVN.
gbjbaanb,
1
Niektóre pliki binarne można (teoretycznie) scalić, np. Dokument ODT.
Donal Fellows
18

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

Peter Mortensen
źródło
1
Assembla (dla każdego obsługiwanego SCM - SVN na liście) jest lepszy niż github, myślę
Lazy Badger
istnieją również smartgit, GitXL itp., programy, które sprawiają, że korzystanie z git jest prostsze
wirrbel,
@LazyBadger, Nigdy o tym nie słyszałem.
Pacerier
16

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

Ian
źródło
8
Korzystanie z gitrozgałęzień i scalania nie jest złożoną operacją. Korzystam nawet z oddziałów w projekcie jednoosobowym, nawet jeśli nie ma wymagań dla wielu wersji. Utrzymanie pracy, której w tej chwili nie możesz kontynuować w oddziale, rozgałęzienie, gdy dowiesz się, że wypróbowanie innego rozwiązania może być znacznie lepsze ... Zgadzam się jednak, że gittrudniej jest się nauczyć.
maaartinus
Za każdym razem, gdy musisz zrobić poprawki błędów w starych wersjach, potrzebujesz rozgałęzienia i scalenia.
1
Dlaczego ludzie nie uważają, że rtęć jest łatwiejsza niż svn lub git?
Warren P
Myślę, że częścią tego jest to, że ponieważ SVN do niedawna nie obsługiwał rozgałęziania i łączenia bez bardzo wysokich kosztów, pozwolił programiście stawić czoła menedżerom, gdy chcieli ciągle zmieniać to, nad czym ktoś pracuje. Narzędzie musi działać w ramach polityki firmy, a także pomaga kształtować politykę firmy.
Ian
14

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.

Peter Mortensen
źródło
git to bardziej „filozoficzne” podejście do kontroli wersji. zaczynasz myśleć o semantyce zatwierdzeń, gałęzi itp. Więc ludzie, którzy chcą używać VCS jako narzędzia do tworzenia kopii zapasowych i dystrybucji, mają trudniejszy czas, ale git nie jest trudniejszy
wirrbel
11

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)
Aleksandrul
źródło
8
  • 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.
Tim
źródło
+1 za problem z uwierzytelnieniem. Zatwierdzenia Git muszą zostać podpisane, a podpisania muszą zostać sprawdzone, co jest trudne.
Chrześcijan
6

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.

GlenPeterson
źródło
2
Inni uderzyli w to, wspominając o „odgórnej kontroli zarządczej”. Jest to kluczowy element dla mojego środowiska - mamy pewne obszary naszych repozytoriów, które muszą być zablokowane tylko do odczytu lub nawet braku odczytu dla niektórych grup użytkowników. Musimy także mieć jedną lokalizację, na którą możemy wskazać i powiedzieć „to jest autorytatywna kopia wzorcowa, jeśli twoja kopia nie pasuje do tego, co jest tutaj, nie jest oficjalna”.
alroc
1
błogosławione repozytorium lidera projektu i poruczników daje kontrolę nad tym, kto może popełnić. Repozytorium Git opublikowane na serwerze z włączonym uwierzytelnianiem HTTP (przy użyciu tych samych modułów apache, które robi svn) wykonuje uwierzytelnianie i mówi, kto może sklonować / wyrejestrować. Jasne, nie jest tak szczegółowy jak svn na uprawnienia do katalogu, ale dla mnie wygląda to bardziej na mikro zarządzanie niż na rzeczywistą potrzebę.
Hubert Kario
@HubertKario - rodzi to pytanie: „Czy Twoi najlepsi programiści powinni spędzać czas na sprawdzaniu kodu innych osób?” Właściwie jestem tak zainteresowany odpowiedzią na to pytanie, że zamieściłem ją tutaj: programmers.stackexchange.com/questions/181817/…
GlenPeterson
5

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

calum_b
źródło
6
Ale kasa / klonowanie jest rzadką operacją. W większości scenariuszy git jest szybszy niż subversion.
rds
5
git clone --depth=1jest twoim przyjacielem, jeśli nie dbasz o historię
Hubert Kario
4

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.

żart
źródło
Czy możesz wyjaśnić przykład branży gier?
Johnny
3

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.

William Payne
źródło
1

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.

Sean McMillan
źródło
-1

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.

Karl Fogel
źródło
1
jest to również łatwe do zrobienia w git; np. git --amend; innym sposobem na to jest git reset - miękka GŁOWA ^, która po prostu cofa się, ale nie zmienia indeksu, i można edytować / ponownie pisać komunikat zatwierdzenia.
doug
Cześć Doug. Tak, możesz to zrobić dla swojego lokalnego repozytorium, ale mówię o tym, kiedy już wypchniesz zmianę gdzie indziej - „git commit --amend” niewiele ci wtedy pomoże. W SVN możesz edytować komunikat dziennika na serwerze centralnym, właśnie dlatego, że istnieje koncepcja serwera centralnego. To właśnie miałem na myśli „niemożliwe z założenia w zdecentralizowanych systemach”. Zmodyfikuję moją odpowiedź, aby była bardziej przejrzysta.
Karl Fogel,
1
Uwielbiam to, jak „można bawić się z historią” jest rzekomo cechą . Uznałbym to za błąd, gdyby nie był zamierzony.
cHao