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:
Czym kierować się przy wyborze systemu kontroli wersji?
- 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.
Ech systemy 3 generacji (np. git) są lata świetlne przed tymi wcześniejszymi (np. svn). Czemu?
Newb napisał(a):
- SVN posiada bardzo wygodne narzędzia np. TortoiseSVN.
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.
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?
- 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.
- 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...
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.
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...
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...
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 -dale remote'agit remote rm? dlaczego, dlaczego, dlaczego...
Składnia poleceń gita nie jest spójna, ale z drugiej strony, stosowanie konsoli nie jest obowiązkowe.
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/
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.
Git no access control - no tak, bo użytkownicy SVN to dzieci, które wymagają opieki. Profesjonaliści nie mają takich problemów.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.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.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.
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.
@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) ;]
@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) ;)
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? :|
Bardzo często tak właśnie jest. A branch jest raczej stosowany jako fork
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. ;)
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 ;)
