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.

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