Konkretne powody wciąż używania Subversion? [Zamknięte]

22

Chcę wybrać system kontroli wersji dla mojej firmy. Jak dotąd wiem, że mam Git, Subversion i Mercurial.

W dzisiejszych czasach widzę, że Git jest najczęściej używany, więc zastanawiam się: czy istnieje jakiś konkretny powód, aby nadal używać Subversion, czy powinienem przejść bezpośrednio do Git?

version-control git svn

— użytkownik1179459
źródło

36

Oboje działają. Ważne jest, czy spełnią one Twoje wymagania, o których nam nie powiedziałeś.

— Matthew Flynn

6

Zobacz Dlaczego używać SVN? Jakieś ukryte zalety (ponad GIT / Mercurial / Bazaar)? na przepełnienie stosu.

— detly

11

Z jakiego argumentu wykluczasz Mercurial?

— mouviciel

8

-1 za subiektywne (przynęty IMHO) sformułowanie i „W tych dniach widzę, że Git jest najczęściej używany” - potrzebne cytowanie. Git jest niezwykle powszechny w świecie open source, ale w przestrzeni korporacyjnej jest znacznie rzadszy. Korpus bardzo podoba się pomysł jednego, centralnego, autorytatywnego repozytorium i bardzo wolno się go zmienia. W przestrzeni korporacyjnej bardziej prawdopodobne jest, że zobaczysz dobry ole CVS niż SVN, nie wspominając o DVCS.

— Keith

4

@RobinWinslow - SVN różni się od Git. Lepiej pasuje do niektórych okoliczności, a gorzej do innych. Osobiście wolę DVCS i oczywiście wolisz Gita, ale oba są subiektywnymi opiniami. Nie są bez wartości, ale nie należą do takiej witryny.

— Keith

46

SVN wcale nie jest martwy. Jest nadal w bardzo szerokim użyciu i wkrótce nie będzie dostępny. SVN jest znacznie prostszy w użyciu niż rozproszona kontrola wersji, szczególnie jeśli nie prowadzisz rozproszonego projektu, który wymaga rozproszonej kontroli wersji.

Jeśli masz tylko jedno centralne repozytorium (to wszystko, czego Twoja firma będzie potrzebować, jeśli są jeszcze wystarczająco małe, aby poradzić sobie bez kontroli źródła), znacznie łatwiej jest używać SVN do interakcji z nim. Na przykład za pomocą SVN możesz pobrać zmiany z repozytorium lub zatwierdzić zmiany lokalne za pomocą jednej operacji, podczas gdy HG i Git wymagają dwóch lub trzech kroków, aby wykonać równoważną pracę.

Dzięki najnowszym wersjom SVN naprawił wiele problemów z wydajnością, które sprawiły, że ludzie wolą HG i Git. Jest teraz znacznie szybszy niż kilka lat temu, a na tym etapie naprawdę nie ma dobrego powodu, aby patrzeć na HG lub Git dla swojego projektu, chyba że faktycznie potrzebujesz zaawansowanych funkcji rozproszonej kontroli wersji.

— Mason Wheeler
źródło

16

Nie do końca zgadzam się z twoimi szacunkami, ale chciałbym dodać jedną ważną kwestię na korzyść SVN: Wiele osób w branży czuje się dobrze z SVN, ale nie zna wystarczającej ilości Git, aby wygodnie z nim pracować. Jeśli cały Twój zespół jest przyzwyczajony do SVN, przejście na Git może być dość kosztowne. (Oczywiście może być również odwrotnie).

— Joachim Sauer

8

Głosowałbym za tym kilkanaście razy, gdybym mógł. Wiele osób lubi modę, ale tak naprawdę nie zastanawiają się, dlaczego mieliby potrzebować rozproszonej kontroli źródła.

— Euphoric

21

@Euphoric: Wiem dokładnie, dlaczego zawsze chcę rozproszonej kontroli źródła w każdym projekcie. Ma istotny efekt uboczny, czyniąc rozgałęzianie i łączenie prostym, oczywistym i niezawodnym. Subwersja jest nadal utknięta w narożnych skrzyniach z rozgałęzieniami, ponieważ wybrany podstawowy model po prostu komplikuje ją.

— Jan Hudec

18

Rozproszona kontrola wersji nie jest „modą”. Jest to ewolucja kontroli źródła, podobnie jak jednoczesna kontrola wersji była ewolucją nad paradygmatem blokowania plików.

— JesperE

6

@MichaelBorgwardt, faktycznie zrobiłem to wiele razy. Jest to o wiele łatwiejsze niż przy wywróceniu, fakt, że wszystko jest lokalne, bardzo pomaga, nie trzeba wyjaśniać interakcji „klient” i „serwer”. Przepływ pracy w git lub hg jest o wiele bardziej naturalny i intuicyjny (jeśli trzymasz się z dala od trudnych elementów, takich jak edycja historii).

— SK-logic

19

Narzędzia klienta nie zostały jeszcze wspomniane. Z pewnością możesz zrobić wszystko za pomocą skryptu wiersza poleceń, ale integracja GUI może naprawdę zwiększyć wydajność.

Pracujemy głównie z Visual Studio; integracja z IDE jest zdecydowanie lepsza w SVN niż w Git. To może się zmienić w przyszłości, ale na pewno ważyłbym to w twojej decyzji tak samo, jak funkcje kontroli wersji.

Podobnie jak wszystko inne, system kontroli wersji nie jest celem samym w sobie, tylko narzędziem, które zabierze Cię tam, dokąd zmierzasz. Wybierz ten, który szybko Cię tam dostanie, w zależności od twojej sytuacji.

— njr101
źródło

To dobra uwaga. Myślę, że jednym z powodów, dla których ludzie wolą Git od SVN, jest to, że Git ma lepsze narzędzia CLI. Ale można to zrównoważyć dobrym GUI SVN innej firmy, takim jak TortoiseSVN w systemie Windows.

— Euphoric

2

Jest to jeden z powodów, dla których zdecydowaliśmy się na Mercurial (i TortoiseHg) nad Git. Zalety rozproszonej kontroli wersji i przyzwoitych narzędzi oraz integracji IDE.

— HappyCat,

15

Jestem fanem Git. Niedawno musiałem przyznać, że jedną z wad Git jest to, że identyfikuje wersje za pomocą skrótów jako przeciwieństwo numerów wydanych przez svn. Numer wydania można łatwiej przekazać telefonicznie lub coś w tym rodzaju.

I to jedyny profesjonalista, jaki mogę sobie wyobrazić. Jeśli naprawdę chcesz polegać na tej funkcji, możesz mieć ją na rozproszonym i / lub scentralizowanym bazarze VCS . W Git są tagi, które mogą służyć do tego celu.

W każdym razie po prostu nie mogłem sobie wyobrazić rozwoju bez szybkiego przełączania gałęzi i ukrywania. Te dwie funkcje same pokonały SVN, gdzie do tej pory pamiętam, że to samo zadanie wymagało utworzenia i sprawdzenia całego drzewa w osobnych katalogach, aby osiągnąć ten sam cel.

Te tak zwane „zaawansowane funkcje rozproszonej kontroli wersji” przychodzą z czasem i nie musisz się ich uczyć na samym początku. Nie bój się ich. Są tutaj, aby ci pomóc, a nie przeszkadzać. I nie ma problemu z utworzeniem centralnego repozytorium dla DVCS.

— Rajish
źródło

1

To jest rzeczywiście dyskusyjne, git potrzebuje tylko wystarczająco dużej części skrótu, aby móc jednoznacznie określić, zwykle wystarcza coś ~ 6 znaków, a nie cały skrót.

— TC1

2

W praktyce nigdy nie przekazujesz hasza git. Możesz użyć dowolnego unikalnego prefiksu skrótu, który zwykle ma 6-7 znaków.

— JesperE

1

@JesperE: Tak, ale liczby wydań SVN rosną sekwencyjnie w czasie, podczas gdy skróty Gita, nawet jeśli je skrócisz, równie dobrze mogą być losowe.

— Keith Thompson,

2

Za pomocą SVN możesz łatwo wyewidencjonować części repozytorium aż do poziomu folderu, natomiast dzięki git dostajesz całe repozytorium, w tym całą historię.

W zależności od sytuacji może to mieć pewne zalety dla SVN

(ma to również pewne duże wady, takie jak ukryte śmieci „.svn” aż po drzewo folderów).

— Richard Nichols
źródło

3

Uwaga: brak śmieci .svn od wersji 1.7 - teraz wszystkie są przechowywane w jednym miejscu.

— gbjbaanb

To nie jest poprawne - git pozwala wyewidencjonować tylko pliki, bez historii, a także można wyewidencjonować tylko części repo - pojedynczych plików, jeśli chcesz. Jest to trochę bardziej skomplikowane niż SVN, ale pojemność jest dostępna.

— Benubird,

2

„Jeśli masz zadanie, które można wykonać w ciągu sześciu godzin, lepiej jest napisać narzędzie, które wykonuje je w 20 minut, nawet jeśli tworzenie narzędzia zajmuje sześć godzin?”

Kontrola wersji rozproszonej to inna bestia do rozwiązania. Wymaga to gruntownej nauki dla każdego programisty. Jeśli masz bufor do obsługi procesu uczenia się dla każdego programisty, powinieneś przejść do dobrego rozproszonego systemu kontroli wersji. Po zakończeniu fazy uczenia się rozproszona kontrola wersji jest znacznie lepsza niż scentralizowana kontrola wersji.

Rozproszona kontrola wersji wydaje się być ewentualnością. Jest tu na bardzo długo, lepiej, żebyśmy się do niego przystosowali wcześniej niż później. Pamiętam tę samą dyskusję, kiedy SVN był nowy i ludzie byli przyzwyczajeni do CVS, podano wiele argumentów za nieużywaniem SVN, ale ostatecznie SVN stał się najpopularniejszym systemem kontroli wersji.

Jeśli firma ma ugruntowaną pozycję z dużą ilością kodu źródłowego w istniejącym systemie kontroli wersji, przejście do nowego systemu jest dużym zadaniem, ale jeśli firma jest mała lub zaczyna działalność, przejście do nowej kontroli wersji jest bardzo łatwe. Ale jeśli pozostaniesz przy starszej kontroli wersji (w nowej konfiguracji), gdzieś w przyszłości trafisz na wąskie gardło, gdzie będziesz musiał ostatecznie zaplanować migrację kontroli wersji.

Widziałem wiele profesjonalnych komentarzy SVN, ale wszystkie mają charakter „SVN nie jest zły”, a nie „SVN jest lepszy”. Dlatego zdecydowanie zalecam wybranie rozproszonej kontroli wersji (takiej jak Git) dla swojego projektu.

EDYCJA Zalety GIT w stosunku do SVN

~~Nie jest wymagany serwer dedykowany~~ Właściwie oba mogą być używane bez serwera.
Może kontynuować rozwój nawet bez połączenia sieciowego.
Zarządzanie oddziałami jest znacznie łatwiejsze.
Lepsze wsparcie z narzędzi CI, takich jak Bamboo

Ktoś wymienił oprzyrządowanie (dla studia wizualnego) jako powód, aby trzymać się SVN. http://gitscc.codeplex.com/ zapewnia obsługę GIT dla Visual Studio.

— Apeirogon Prime
źródło

6

SVN ma uchwyt plików binarnych lepiej niż Git lub HG.

— Fałszywe imię

2

„W przyszłości natrafisz na wąskie gardło, w którym będziesz musiał w końcu zaplanować migrację kontroli wersji ...” Niestety, nie mogę się zgodzić, że to dobry powód, aby dokonać tego dzisiaj. Pracowałem nad wieloma projektami, w których takie podejście prowadzi do komplikowania spraw, niż jest to konieczne, a projekt jest anulowany na długo, zanim będzie mógł skorzystać z tych przyszłych korzyści. Czasami wystarczająco dobry, jest wystarczająco dobry. Trzymaj się YAGNI i bierz to, co wykonuje dzisiaj. Później będzie wystarczająco dużo czasu, aby się martwić o migracje. Przynajmniej nadal będziesz mieć projekt.

— njr101

2

Once the learning phase is over Distributed Version Control is much better than Centralized Version Control.Całkowicie się z tym nie zgadzam. W niektórych okolicznościach może mieć pewne odczuwalne korzyści, ale coś tak prostego, jak numer wersji w svn, który jest czytelny dla człowieka, jest ogromną korzyścią w wielu organizacjach.

— TZHX

1

@apeirogon - Wszystko sprowadza się do tego, co zamierzasz umieścić w repozytorium. Sam HEAD jednego z głównych repozytoriów, z którymi pracuję, ma 11,1 GB! Gdybym miał to w repozytorium Git / bzr / hg, prawdopodobnie zajęłoby to ponad 100 GB.

— Fałszywe imię

1

Oczywiście dzieje się tak, ponieważ to konkretne repozytorium jest pełne plików PCB i modeli 3D, które są w formacie binarnym i nie zajmują dużo miejsca. Zalecenie tutaj (Electronics.SE, np. Dla osób przechowujących pliki do projektowania PCB itp.) Jest bardzo odmienne niż dla kogoś, kto przechowuje kod źródłowy.

— Fałszywe imię

1

czy byłby jakiś konkretny powód, aby używać Subversion w tych dniach

Oprócz obsługi narzędzi w IDE (których nie używam) - nie, nie. Oczywiście SVN może być bardziej znany, ale to jedyny powód, dla którego zarówno Hg, jak i Git są bardzo łatwe (i bardzo szybkie) do nauki.

Tak, istnieją wszystkie złożone przewodniki, które opisują, jak Git jest trywialny, gdy zrozumiesz, że gałęzie są po prostu homeomorficznymi endofunkorami mapującymi podfoldery przestrzeni Hilberta. ¹

Nie rozumiem tego Ale wiesz co? To nie ma znaczenia Nie musisz znać żadnej z tych rzeczy, aby korzystać z Git.

W większości Git i Hg są łatwe w użyciu i mają zdecydowane zalety w stosunku do SVN. Słoń w pokoju oczywiście rozgałęzia się: gałęzie po prostu działają w Git i Hg. Natomiast w SVN są w najlepszym wypadku bolesne, aw najgorszym złamane (łączenie wielu głów).

Oczywiście nadal możesz używać SVN. Nadal możesz także korzystać z systemu Windows XP. Jednak większość użytkowników, którzy próbowali obu, zgadza się, że jedna z alternatyw jest znacznie lepsza.

¹ Tak, rozumiem, że to żart. Myślę.

— Konrad Rudolph
źródło

Samouczek Git z homeomorficznymi endofunkorami mapującymi podfoldery przestrzeni Hilberta? Muszę to przeczytać! Ale czy to raczej nie dotyczy Darcs, które są napisane w Haskell (do którego myślę, że odnosi się do endofunkcji ) i inspirowane mechaniką kwantową (stąd przestrzeń Hilberta )? Naprawdę nie rozumiem, co Git i HG mają wspólnego z tymi rzeczami.

— leftaroundabout

@leftaroundabout To żart. Opis nie jest nawet dokładny (o ile mi wiadomo). Jest to riff w wielu samouczkach, które zaczynają się od: „gałęzie git są łatwe, gdy zdasz sobie sprawę, że ...”, a potem jest złożona metafora specyficzna dla domeny.

— Konrad Rudolph

1

Czy zastanawiałeś się kiedyś nad tym, że wszystkie zbyt skomplikowane samouczki istnieją z jakiegoś powodu? A po co to w ogóle? Nigdy nie rozumiałem obsesji tłumu DVCS związanej z rozgałęzianiem, a następnie ponownym włączaniem gałęzi do każdej drobiazgi. To zawsze wydawało mi się rozwiązaniem problemu. Ponowna integracja oddziału w SVN jest trudna, ponieważ jest to naprawdę głupia i koncepcyjnie niewłaściwa rzecz do zrobienia , a ja naprawdę nie znajduję żadnego argumentu sprowadzającego się do „nasz produkt znacznie ułatwia robienie złych rzeczy” bardzo przekonujący.

— Mason Wheeler,

1

Co do pracy nad wieloma zmianami równolegle, przyznaję, że to trochę bolesne, ale właściwym rozwiązaniem są półki, które są planowane na następną wersję SVN. I przez większość czasu, jeśli pracujesz nad wieloma zmianami w tym samym czasie (a zwłaszcza, jeśli robisz to konsekwentnie!), To dowód na szerszy problem, który powinien zostać rozwiązany na poziomie organizacji, a nie włączony w nowym przybory. (Patrz wyżej, ponownie „nasz produkt znacznie ułatwia robienie złych rzeczy” i klasyczny artykuł Joela na temat przełączania zadań ludzkich).

— Mason Wheeler,

3

@KonradRudolph Scalanie gałęzi z powrotem do pnia działa dobrze w najnowszych wersjach SVN. Od kilku lat robi się coraz lepiej, a teraz jest bardzo dobrze.

— Adam Bruss,