SVN vs GIT

Próbowałem używać git-svn, ale wymiękłem po 4 godzinach klonowania repo a końca nie było widać. Teraz po prostu zainicjowałem repo gita wewnątrz repo SVNa i korzystam z niego normalnie, robiąc sobie zwykłe gitowe branche, potem to merge'uje i wrzucam do SVNa. Idealnie nie jest, ale daje radę.

Zna ktoś jakieś dobre źródło w którym są przedstawione zalety git nad svn w celu przekonania osób do gita ?

@Złoty Młot, jeżeli komuś nie wystarcza, że cały cywilizowany świat używa gita, hipsterzy używają hg lecz idea ta sama, to nie ma na niego argumentów.

Obejrzyjcie sobie nagrania z Linusem Torvaldsem na Youtube jak mówi o Gicie, to odechce się wam SVNów i będziecie wiedzieć co dobre ;)

Koziołek napisał(a):

jeżeli komuś nie wystarcza, że cały cywilizowany świat używa gita, hipsterzy używają hg lecz idea ta sama, to nie ma na niego argumentów.

LukeJL napisał(a):

nagrania z Linusem Torvaldsem na Youtube jak mówi o Gicie, to odechce się wam SVNów

„cały cywilizowany świat” nie jest dla mnie argumentem, bo wyznaję zasadę że dobre jest to co jest dobre a nie to czego ludzie używają.
Linus wyzywający wszystkich od głupków również nie jest dla mnie żadnym argumentem.
Ani nie jest nim poroniony command line Gita, i jego czasem zbyt zaawansowany imbecylizm.

Ale jest - i to silnym - argumentem sama idea systemu rozproszonego. Że na lokalnym repozytorium robisz commity i dopiero później robisz push na zdalne - dzięki temu commity można robić często i małe (kilkulinijkowe), a nie wielkie z kilku dni.
Że Git jest szybki przy wielkich operacjach.
Że masz całe repozytorium u siebie na dysku - historię wszystkich branchy - i możesz pracować bez chwilowego dostępu do „głównego” repo, robiąc commity i branche.
Że nie marudzi o konflikcie w przypadkach trywialnych, co jest zmorą SVN-a.
Że dzięki powyższemu merge jest na porządku dziennym, a nie jest wielką, straszną operacją.
Że kiedy (w przypadku projektów open source) autorzy się rozmyślają i zamykają repo to wiele osób ma klon u siebie - i to nie tylko ostatni (albo nieostatni) commit, ale całą historię.
Że „postawienie” repo zdalnego jest operacją trywialną i nie wymaga żadnego dodatkowego softu serwerowego poza dostępem na serwer przez ssh. (a nawet przez windowsowy udział się da, ale wtedy niestety zamula)

I choć wykonanie Gita pozostawia sporo do życzenia (na granicy wtf - nie miałem do czynienia z hg, nie mam porównania) to pod względem wygody pracy to zupełnie inna liga niż Subversion a przed nim CVS.

SVN:

• (-) nie znalazłem dobrego klienta GUI pod Linux
• (-) nie znam żadnego fajnego publicznego serwisu który pozwala na założenie repo za darmo
• ma branche i tagi - obsługiwane jako normalne katalogi, ich tworzenie to wg instrukcji komenda wydajna bo zdalna i polegająca mniej więcej na zrobieniu linka symbolicznego, korzystanie z nich zależy od użytkowników: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.commonpatterns.html
• z command line bardzo rzadko się zacina (i potrzebny svn cleanup)
• (-) wtyczka do Eclipse potrafi się zaciąć i pokazywać stary stan lokalnej kopii (potrzebny wtedy Update to HEAD)

GIT:

• (+) są klienty GUI na Linux
• (+) są publiczne serwisy do zakładania repo za darmo: github, bitbucket
• command line podobny (potrzebna dodatkowa komenda push)

Edit: https://svnvsgit.com/

LukeJL napisał(a):

Obejrzyjcie sobie nagrania z Linusem Torvaldsem na Youtube jak mówi o Gicie, to odechce się wam SVNów i będziecie wiedzieć co dobre ;)

GIT jest lepszym wyborem ale jeżeli ktoś używa w jakimś projekcie SVNa i to mu się sprawdza to nie widzę powodu żeby nagle to wszystko rzucił i migrował na GITa.

Jedyny "minus" gita jaki widzę, jest taki że "there is more than one way to do it". Daje to większą elastyczność, ale jednocześnie może być utrudnieniem dla nowych użytkowników.

Trochę bardziej serio. SVN ma jedną ogromną przewagę nad gitem. Na chwilę obecną jest bardzo dobrze zintegrowany z pakietem Office i pozwala na porównywanie dokumentów worda, excela czy powerpointa bez sztuczek z konwersją do np. markdown (jak robi pandoc). Jest to o tyle ważne, że wielu użytkowników nie ogarnia wbudowanego śledzenia zmian w dokumentach, albo z jakiegoś powodu nie może go użyć; osadzone obiekty, zakresy nazwane, niektóre content kontrolki nie działają ze śledzeniem zmian. Dlatego jest on fajnym rozwiązaniem gdy mamy do śledzenia pliki offica (w tym formaty binarne)

SVN potrafi merge'ować pliki binarne(przydatne przy tworzeniu np. gier).

Wybitny Kot 123 napisał(a):

SVN potrafi merge'ować pliki binarne(przydatne przy tworzeniu np. gier).

A jak robisz review dla zmian w pliku binarnym? Jak rozwiązujesz konflikty?

@Wibowit: podpinasz edytor, który potrafi to zrobić. To co pisałem wyżej n.t. plików w starym formacie office. BTW, ciekawostka git nie skaluje się dobrze przy dużych projektach (dziesiątki tysięcy plików). Przy czym SVN nie jest tu lepszy.

Co to znaczy, że się nie skaluje? Na tym repo leży dużo plików i jakoś to działa: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git

git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
Cloning into 'linux'...
remote: Counting objects: 5164230, done.
remote: Total 5164230 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (5164230/5164230), 893.37 MiB | 3.27 MiB/s, done.
Resolving deltas: 100% (4331655/4331655), done.
Checking connectivity... done.
Checking out files: 100% (57202/57202), done.

ATSD:
A dla nowego formatu Office to działa? Wydaje mi się, że są małe szanse, bo nowe formaty Office to pliki ZIP, a tu średnio można zrobić merge skoro lekka zmiana nieskompresowanych danych może pociągnąć za sobą dużo większe zmiany skompresowanych danych. No chyba, że będziemy mieć narzędzie, które rozpakuje pliki, zrobi merge na rozpakowanych i spakuje z powrotem. Tyle, że w takim przypadku wsparcie od SVN byłoby bez znaczenia.

Nowe formaty office, to zipowany XML. Nawet coś takiego sami wyrzeźbiliśmy jak trzeba było robić diffa bez rejestru zmian po stronie dokumentu (kod w scali, bo porównanie drzew to banał w sumie). W przypadku SVNa jest to o tyle proste, że on ma do tego wtyczki :) Przy czym gita też można tak skonfigurować.

No właśnie skonfigurować. W przypadku gita najłatwiej jest:

[diff "bin"]
    textconv = hexdump -v -C

i mieć nadzieję, że mamy hexdumpa w systemie. W przypadku SVNa:

svn diff --force obrazek.png

i otrzymujesz „binarny diff”. W dodatku działa wszędzie.

Co do skalowania. Microsoft przeszedł w pewnym momencie na gita i miał problemy. Wszystko rozbiło się o kombinację „dużo dużych plików”.

IMO, obecnie git i tylko git. Czekam, aż semantic VCS stanie się powszechniejszy.

W zasadzie to gościom chodzi o to, że jak nawpychają do repo dużą ilość danych to wtedy to się ślimaczy:

The largest challenge Git faces in the enterprise arguably stems from its own limitations and performance problems when dealing with large numbers of files or very large files. Git repositories become so slow and unwieldy as they grow that the largest practical size is broadly recognized as being between 1GB and 2GB of content.

Nie napisali nic o dziesiątkach tysięcy plików.
Przy repozytoriach ważących więcej jak 2 GB i tak warto je podzielić na mniejsze, z wielu względów.

Tyle tylko, że jak podzielisz repo to zaczynają się problemy z zarządzaniem dostępami (trzeba to robić).

A dla nowego formatu Office to działa? Wydaje mi się, że są małe szanse, bo nowe formaty Office to pliki ZIP, a tu średnio można zrobić merge skoro lekka zmiana nieskompresowanych danych może pociągnąć za sobą dużo większe zmiany skompresowanych danych. No chyba, że będziemy mieć narzędzie, które rozpakuje pliki, zrobi merge na rozpakowanych i spakuje z powrotem. Tyle, że w takim przypadku wsparcie od SVN byłoby bez znaczenia.

Raczej trzymałbym pliki office'a w repo w postaci rozpakowanych katalogów - dzięki temu Git zarządzałby zawartością. Pakowanie i rozpakowywanie robiłby jakiś skrypt automatyzujący to zadanie.

Z artykułu MS wynika, że narzekają oni na to, że nie ma darmowego narzędzia, którym zarządzałoby się wieloma repozytoriami:

Another set of challenges revolves around hosting so many repositories and protecting their content. Git includes its own daemon for easy hosting, but such hosting is completely open. It requires no authorization, so anyone on the network can see or do anything. That works nicely for a variety of use cases, but it’s a recipe for ulcers in the enterprise.
(...)
These shortcomings explain the explosion of third-party hosting tools and services such as GitHub, GitLab, and Atlassian Stash, all of which may involve their own trade-offs.

Wydaje mi się to trochę naciągane. Z jednym dużym repo nie dałoby się podzielić go na obszary z różnymi poziomami dostępu. Więc jak jedyne co robimy to dzielimy to możemy zostawić tak jak było, czyli dla każdego repozytorium dać te same prawa, które wcześniej miało duże repo.

Yyy ale przecież można repo postawić na Linuksie z kontem shellowym po SSH (żadnego dodatkowego demona - tylko sshd) i uprawnienia ustalać do woli, autoryzację po kluczu SSH, itp.

Chyba że ja nie rozumem natury problemu :-)

Koziołek napisał(a):

Tyle tylko, że jak podzielisz repo to zaczynają się problemy z zarządzaniem dostępami (trzeba to robić).

Wystarczy, że zapis jest ograniczony dla członków zespołu pracującego nad aplikacją znajdującą się w danym repozytorium i problemu nie ma.
Tzn. problemy mogą mieć organizacje biurokratyczne, które same sobie jakieś problemy wytwarzają, ale o to wątek o gicie, a nie o patologiach.

Wibowit napisał(a):

Z artykułu MS wynika, że narzekają oni na to, że nie ma darmowego narzędzia, którym zarządzałoby się wieloma repozytoriami:

Jakiego artykułu MS?

Wibowit napisał(a):

W zasadzie to gościom chodzi o to, że jak nawpychają do repo dużą ilość danych to wtedy to się ślimaczy:
Nie napisali nic o dziesiątkach tysięcy plików.
Przy repozytoriach ważących więcej jak 2 GB i tak warto je podzielić na mniejsze, z wielu względów.

Napisali, ale nie w tym artykule na infotech (bo on w ogóle pisał facet od Perforce - którego BTW Microsoft używał wcześniej), tylko w ogłoszeniu Git VFS:

For example, the Windows codebase has over 3.5 million files and is over 270 GB in size.
#

W ogóle polecam cały wątek na reddicie gdzie ludzie z MSFT mówią o sensie tego rozwiązania, jak i m.in. dlaczego mają jedno gigantyczne repo dla Windows. Z kolei Google ma monorepo dla wszystkiego, tak BTW ;-)

git powstał by utrzymywać historię kodu a nie historię binarek.
Zrzędzenie, że git nie jest szybkie w takim scenariuszu, to jak zrzędzenie, że są problemy zaoraniem pola za pomocą Ferrari mimo, że ma silnik o odpowiedniej mocy.