SVN vs GIT

0

Witam,
Zastanawia mnie, czy jakiś z tych dwóch systemów kontroli wersji jest na tyle dobry, że można powiedzieć że we większości zastosowań wyparł ten drugi?

Wydaje mi się, że główna różnica z punktu widzenia użytkownika jest następująca:

  1. W gicie najpierw robi się commit lokalny, a następnie zdalny.
  2. Git jest szybszy niż SVN.
  3. Git zużywa mniej HDD.
  4. SVN posiada lepszą kontrolę nad rolami.
  5. SVN posiada bardzo wygodne narzędzia np. TortoiseSVN.

Czym kierować się przy wyborze systemu kontroli wersji?

0

SVN posiada lepszą kontrolę nad rolami.

Tzn?

0

Na stronie GITa w porównaniu z SVN znalazłem, że pod tym względem system konkurencyjny jest lepszy tzn. większe możliwości ustawianie uprawnień, kont, kontroli i współdzielenia zasobów niż system konkurencji.

3
  1. Nie odczuwam potrzeby posiadania TortoiseXXX ani niczego w tym rodzaju - IDE z których korzystam mają sensowną obsługę XXX.
  2. Sprawdź jakie dokładnie są różnice w tej kontroli uprawnień i na postawie tego zdecyduj.
  1. W gicie najpierw robi się commit lokalny, a następnie zdalny.

Niet. Commit to commit, a push to wysłanie zmian do zdalnego repo, a nie zdalny commit.

0

Tak zrobię, dzięki.

8

Ech systemy 3 generacji (np. git) są lata świetlne przed tymi wcześniejszymi (np. svn). Czemu?

  1. Dwupoziomowe commity. Wyobraź sobie że wprowadzasz poprawki do jakiegoś kodu w pracy. Kod jest skomplikowany i fajnie byłoby commitować małe fragmenty żeby łatwo było potem się wycofać ze zmian. SVN na to nie pozwoli, bo commit może lecieć tylko do głównego repozytorium (a tego zrobić nie możesz bo popsujesz wszystkim innym buildy). Możesz zrobić branch, ale potem drugie tyle czasu zejdzie na merge. Systemy 3 generacji pozwalają commitować do zdalnego repozytorium a dopiero cały działający kod wrzucić do głównego streamu.
  2. Zmiany w kodzie zapisywane jako change-set a nie jako kolejna wersja pliku. Dzięki temu jeśli 2 osoby modyfikują ten sam plik i każda z nich doda sobie swoją metodę to system 3 generacji automatycznie to sobie scali bo widzi że te zmiany nie konfliktują. SVN oczywiście będzie wymagał ręcznego scalania, bo dla niego diff pokazuje konflikty. Drugą zaletą tego rozwiązania jest możliwość wycofywania change-setów. Wyobraź sobie że przez 3 dni scalałeś kody z różnych branchy, a na koniec okazało się że Mietek w swoim coś popsuł (a jego oczywiście scalałeś jako pierwszy) ale poprawka zajmie mu kilka dni. W SVNie masz tylko możliwość reverta do sytuacji sprzed całego scalania...
1
Newb napisał(a):
  1. SVN posiada bardzo wygodne narzędzia np. TortoiseSVN.

http://code.google.com/p/tortoisegit/ :)

0

Na GIT możesz pracować lokalnie - to chyba największy plus.
Aktualizuję sobie soft lokalnie ile wlezie (mam kolejne wersje) a dopiero gdy przekompiluję całość i przetestuję wrzucam na publiczne repozytorium.
AFAIK na SVN tego nie zrobisz albo będzie to upierdliwe.

0

Witam wszystkich z 4programmers. Wiem, archeologia. Minęły ponad trzy lata. :D Czy z obecnej perspektywy rozwoju SVN (na dzisiaj 1.9.3) opisane bolączki SVN nadal występują w nowszych wersjach? U nas praca będzie odbywała się w praktyce tylko lokalnie. Więc zaleta rozproszonej pracy GIT'a nie jest tak wielka z mojego punktu widzenia.

Shalom napisał(a):

Ech systemy 3 generacji (np. git) są lata świetlne przed tymi wcześniejszymi (np. svn). Czemu?

  1. Dwupoziomowe commity. Wyobraź sobie że wprowadzasz poprawki do jakiegoś kodu w pracy. Kod jest skomplikowany i fajnie byłoby commitować małe fragmenty żeby łatwo było potem się wycofać ze zmian. SVN na to nie pozwoli, bo commit może lecieć tylko do głównego repozytorium (a tego zrobić nie możesz bo popsujesz wszystkim innym buildy). Możesz zrobić branch, ale potem drugie tyle czasu zejdzie na merge. Systemy 3 generacji pozwalają commitować do zdalnego repozytorium a dopiero cały działający kod wrzucić do głównego streamu.
  2. Zmiany w kodzie zapisywane jako change-set a nie jako kolejna wersja pliku. Dzięki temu jeśli 2 osoby modyfikują ten sam plik i każda z nich doda sobie swoją metodę to system 3 generacji automatycznie to sobie scali bo widzi że te zmiany nie konfliktują. SVN oczywiście będzie wymagał ręcznego scalania, bo dla niego diff pokazuje konflikty. Drugą zaletą tego rozwiązania jest możliwość wycofywania change-setów. Wyobraź sobie że przez 3 dni scalałeś kody z różnych branchy, a na koniec okazało się że Mietek w swoim coś popsuł (a jego oczywiście scalałeś jako pierwszy) ale poprawka zajmie mu kilka dni. W SVNie masz tylko możliwość reverta do sytuacji sprzed całego scalania...
4

Co rozumiesz przez "lokalnie"? Bez sieci? Bez centralnego serwera?

Z wyjątkiem tendencji masochistycznych albo poszanowania dla tradycji i technologii rodem z XIX wieku, nie ma żadnych powodów, aby używać SVN, bez względu na wielkość zespołu.

0

Haha, mam na myśli openspace bez zdecentralizowanego środowiska programistów pracujących w różnych lokalizacjach.

0

git ma denerwujący commandline. dlaczego gdy próbuję wyświetlić brancze na remocie to zamiast tego mi tworzy branczę o nazwie takiej jak remote? :-) którą potem nie wiadomo jak usunąć bo jest "ambiguous object name"? dlaczego usunięcie branczy to git branch -d ale remote'a git remote rm? dlaczego, dlaczego, dlaczego...

0

Po jakimś czasie można się przyzwyczaić do commandline'a, a dziwne polecenia zapamiętać, ew. ściągnąć jakąś nakładkę graficzną.

Tym niemniej jak się wie co się robi, i jak działają gałęzie, i zna się różne przydatne polecenia to można wyczyniać cuda. Nie wiem po co ktoś miałby wracać do SVN.

U nas praca będzie odbywała się w praktyce tylko lokalnie. Więc zaleta rozproszonej pracy GIT'a nie jest tak wielka z mojego punktu widzenia.

Lokalnie to by było przy jednym komputerze. Jeśli siedzicie na jednym openspejsie to też wasza praca jest do pewnego stopnia rozproszona. Mając Gita jest ta zaleta, że na każdym kompie jest backup, na każdym kompie ktoś może zrobić sobie z 10 gałęzi na własne potrzeby, albo przeglądać historię do woli...

systemy scentralizowane jakoś w ogóle mi nie pasują do pracy zespołowej. Z drugiej strony do pracy w pojedynkę też nie pasuje system scentralizowany, bo po co odpalać serwer SVN, jeśli wystarczy zrobić git init i każdy katalog może stać się repo...

0

Dzięki za odpowiedzi. :-)

0
Azarien napisał(a):

git ma denerwujący commandline. dlaczego gdy próbuję wyświetlić brancze na remocie to zamiast tego mi tworzy branczę o nazwie takiej jak remote?

To niesamowite, że udało Ci się coś takiego osiągnąć. Nie sądzę, żeby komukolwiek, kiedykolwiek coś takiego się przydarzyło.

dlaczego usunięcie branczy to git branch -d ale remote'a git remote rm? dlaczego, dlaczego, dlaczego...

Składnia poleceń gita nie jest spójna, ale z drugiej strony, stosowanie konsoli nie jest obowiązkowe.

0

ogolnie to chyba dopiero niedawno git przescignal svn w sensie używania go? bo zanim się przeskoczy na inny system kontroli wersji to może zająć trochę czasu.
Więc ogólnie chyba dalej svn jest dość często używany ?

ja wole gita , ale są też stronki co udowadniaja co innego ;)
https://svnvsgit.com/

7
Złoty Młot napisał(a):

ogolnie to chyba dopiero niedawno git przescignal svn w sensie używania go? bo zanim się przeskoczy na inny system kontroli wersji to może zająć trochę czasu.
Więc ogólnie chyba dalej svn jest dość często używany ?

Jest używany, jeszcze długo będzie, i pewno nigdy nie przestanie. Za wybór systemu kontroli wersji odpowiadają zazwyczaj "doświadczeni" ludzie, a że spora część z nich jest tłukami, która dawno przestała się rozwijać, to wybierają najnowszą technologię z początku ich kariery, czyli SVN. Git jest w końcu zbyt nowoczesny (10 lat to przecież chwila).

ja wole gita , ale są też stronki co udowadniaja co innego ;)
https://svnvsgit.com/

Ciekawe bardzo.

  1. Pierwsze słyszę, aby ktokolwiek twierdził, że repozytoria Gita są mniejsze. No, ale niech im będzie, walka z samodzielnie wymyślonym wrogiem jest łatwiejsza.
  2. Branch w SVN jest operacją ZDALNĄ, więc czas jego wykonania zależy od połączenia z netem. Jak pracujesz w banku, do którego się łączysz przez VPN, a serwer stoi na jakiejś słabej VMce, to branchowanie trwa minuty. Nie wspominając już o tym, że jak nie masz sieci, to nie zrobisz brancha.
  3. W projektach korzystających z SVN raczej był zakaz stosowania jakichś "magicznych" rozwiązań, zawsze musiałem wybierać startowe rewizje. Widać SVNowi devopsi słabo wierzą w jego możliwości. Ale to naprawdę nie jest problem. Problemem jest to, że SVN w ogóle nie potrafi mergować.
  4. Trzeba jeszcze mieć wersję 1.7 i zmigrowane do niej repozytorium. A jak klient tego nie potrzebuje, bo dla niego to tylko zbędne koszty, to programista się musi męczyć.
  5. Patrz pkt. 1.
  6. Tu już przywalili jak łysy grzywką o parapet...
    a) no access control - no tak, bo użytkownicy SVN to dzieci, które wymagają opieki. Profesjonaliści nie mają takich problemów.
    b) full copy of repository on every computer - to raczej główna zaleta niż wada. Tylko SVNowiec mógł wpaść na pomysł, że to źle, bo oni wszak lubują się w ogromnych repozytoriach, zawierających tysiące oddzielnych aplikacji. Profesjonaliści nie mają takich problemów.
    c) no exclusive files locks - to naprawdę straszne, że nikt nie może mi zabronić edytowania pliku. Jak się pisze klasy na 10 tysięcy linii kodu to faktycznie może być problem. Ponownie - profesjonaliści nie mają takich problemu.
  7. Ciekawe jak działają duże repozytoria SVN, zwłaszcza gdy przeglądamy historię w poszukiwaniu zmiany, która coś zepsuła. Ciekawe swoją drogą, czy SVNowcy słyszeli np. o mikroserwisach.
  8. Problem natury higienicznej. Jeśli używa się zdrowego rozsądku i racjonalnego podejścia do pracy, to nie występuje. No, ale to rzeczy chyba nieznane w świecie SVN.
  9. To fakt - nie zawsze. 95% to nie jest zawsze.
  10. No to fakt, Gita trzeba się nauczyć. Nie tylko obsługi, ale też jego filozofii i podejścia do pracy. A, że SVNowcy tego nie robią, to wiecznie narzekają.
  11. Kolejny problem natury higienicznej. Nie zmienia się nazwy pliku i jego zawartości jednocześnie, trzeba to podzielić na dwa commity. No, ale jak mieliby to zrozumieć SVNowcy, którzy robią góra jeden commit dziennie.
  12. To nie jest problem związany z kontrolą wersji, bo po prostu nie przechowuje się tajnych informacji razem z kodem. Do tego celu służy konfiguracja serwera CI, do której dostęp mają dostęp tylko admini.
  13. Jeśli jedna osoba pracuje nad niemerdżowalnym zasobem, to inne go nie ruszają. Nie trzeba do tego zaawansowanego systemu uprawnień, wystarczy użycie mózgu, a potem ust albo np. maila. Generalnie komunikacja to podstawa w pracy.

Szkoda, że nie obalili "mitów" z konfliktem wersji na identycznej linijce dodanej w dwóch różnych gałęziach, z koniecznością pracy zdalnej, z niemożnością przeglądania historii bez połączenia z internetem...

Cały "problem" wynika z tego, że zatwardziali SVNowcy, którzy są przyzwyczajeni do niewygody i powolnego działania, do robienia jednego commita na tydzień i do ciągłego rozwiązywania fałszywych konfliktów, nigdy nie zrozumieją, że system kontroli wersji to narzędzie dla programisty. Nie dla zespołu, nie dla managera, nie dla administratora, nie dla gościa od deploymentu, ale dla programisty. Dlatego nie rozumieją narzędzia, które daje programiście wolność organizacji pracy; które pozwala na zapisanie swojego dotychczasowego toku myślenia, a następnie go porzucenie w celu wypróbowania różnych sposobów rozwiązania problemu; które daje możliwość powrotu do poprzedniego pomysłu bez tracenia całodziennej pracy.
Z tego samego powodu, poziom recydywy wśród osób odsiadujących wieloletnie wyroki jest taki duży. Oni także nie rozumieją wolności, po wyjściu z więzienia nie potrafią się odnaleźć w nowej sytuacji, więc znowu popełniają przestępstwo, żeby do więzienia wrócić, bo tylko w znanym sobie miejscu czują się bezpiecznie.

0

Mnie najbardziej ciekawi, że komuś się chciało nasmarować tyle tekstu, żeby niby udowodnić wyższość svn nad git :S

0

A w zasadzie to czy przy nawet duzym projekcie to czy migracja z svn na git moze byc jakos szczegolnie skomplikowana?

0

Przypomina mi się wojna między Commodore i Atari. Każdy używa to co mu pasuje a nie to co modne. Tak jak napisał @somekind, to narzędzie dla programisty a nie do lansu.

0

a jest jakiś guide from git to svn?

niestety czeka mnie zabawa bdsm z svn...

0

@Złoty Młot tu wielkiej filozofii nie ma. Wyobraź sobie że jedyne co możesz zrobić to push (nazywane tutaj commit) oraz pull (nazywane update) ;]

0

Niby tak, ale zrobilem sobie testowe repo to z mergowaniem branchy mialem juz wtf ;)

0

@Zimny Młot dlatego nie wspomniałem nic o branch ani merge. Powtarzam: wyobraź sobie że jedyne co możesz zrobić to push (commit) oraz pull (update) ;)

0
Shalom napisał(a):

@Zimny Młot dlatego nie wspomniałem nic o branch ani merge. Powtarzam: wyobraź sobie że jedyne co możesz zrobić to push (commit) oraz pull (update) ;)

mam rozumiec, ze ludzie pracujacy na svn nie uzywaja branchy i nie pracuja nad jednym kawalkiem rownoczesnie? :|

1

Bardzo często tak właśnie jest. A branch jest raczej stosowany jako fork

5

niestety czeka mnie zabawa bdsm z svn...

Możesz używać gita (git svn), czyli lokalnie masz gita tylko zamiast git push robisz git svn dcommit.

0

Szczerze mówiąc, nie chciało mi się czytać wszystkich postów.
Wątek powstał w roku 2012. Mamy rok 2016. Tu nie ma o czym dyskutować.
Git to jest standard i lepszy system, a SVN, to przeżytek obecny chyba tylko w systemach legacy, przy których pracują ludzie starej daty bojący się zmian.
Nie wiem, czy ktoś przy zdrowych zmysłach wybrałby SVN do nowego projektu. ;)

0

Widze, ze nawet gitextensions ogarnia git-svn, tak trochę.

0
wiciu napisał(a):

Szczerze mówiąc, nie chciało mi się czytać wszystkich postów.
Wątek powstał w roku 2012. Mamy rok 2016. Tu nie ma o czym dyskutować.
Git to jest standard i lepszy system, a SVN, to przeżytek obecny chyba tylko w systemach legacy, przy których pracują ludzie starej daty bojący się zmian.
Nie wiem, czy ktoś przy zdrowych zmysłach wybrałby SVN do nowego projektu. ;)

wiesz, jak jest ogromny projekt to moze byc ciezko sie przesiasc z dnia na dzien ;)

1 użytkowników online, w tym zalogowanych: 0, gości: 1