Zastanawia mnie jaki system kontroli wersji jest najlepszy (szybkość, łatwość obsługi, możliwości).
Od sporego czasu używam SVN-a (VisualSvn na winde + Tortoise) i jakoś działa aczkolwiek czasem potrafi wypluć jakieś kosmiczne błędy, które logicznie nie powinny mieć miejsca.
Dlatego też chciałem was zapytać o osobiste doświadczenie i rekomendacje do jednego z wymienionych systemów. Chyba, że są inne jeszcze lepsze.
Bardzo bym prosił również o podanie w formie listy zalet i wad każdego z systemów.
Osobiście chwalę sobie GITa, za to, że jest on w przeciwieństwie do SVNa systemem rozproszonym, a nie scentralizowanym.
Jaką to możliwość stwarza? Bo o ile dobrze rozumiem, to Backup.
http://progit.org/book/ - rozdział 1.1 i 1.3 - przeczytasz w 10 minut a powinieneś mieć już jakieś rozeznanie w plusach i minusach obu koncepcji.
Przyznam, że nie mam ogromnego doświadczenia z SVN, z GIT'em dopiero niedawno zacząłem. Nie mam całkowicie żadnego z CVS, którego trudno nazwać "systemem kontroli wersji"
Git w porównaniu do SVN ma więcej możliwości, jest jak wspomniał Crozin systemem rozproszonym, co za tym idzie nie musi (może) istnieć serwer główny projektu. Można korzystać z repozytorium macierzystego, ale nie ma takiej konieczności. W zasadzie każdy ma u siebie swoje repozytorium i commit nic nie wysyła, tylko uaktualnia lokalne repozytorium, dopiero popchnięcie tego dalej (np do repo macierzystego) lub pociągnięcie przez kogoś innego, skutkuje tym, że projekt zobaczy światło dzienne
Ostatnio zauważyłem, że dużo projektów przechodzi na GIT'a, http://pl.wikipedia.org/wiki/Git_(oprogramowanie)#U.C5.BCytkownicy sporo dużych projektów z niego korzysta.
Proponuję poczytać o tym systemie, możliwości jest na prawdę dużo. Materiały:
Od svna/cvsa to ja wole tarballe z diffami, wygodniejsze w uzyciu. mercu to praktycznie klon gita z brakiem kilku funkcjonalnosci i w pythonie (jezeli zamierzasz cos dopisywac to cie to obchodzi), ciut mniej wydajny od gita ale dla malych/srednich projektow starczy.
http://www.youtube.com/watch?v=4XpnKHJAok8
mnie strife zainteresował ostatnio bazaarem, taki git tylko wydaje mi sie z bardziej intuicyjną składnią.
Oglonie dla mnie najwieksza zaletą gita (akurat to mi przypadło jakos do gustu, reszty nie testowałem) to:
* że nie tworzy ci w każdym katalogu ukrytego katalogu (jak to ma miejsce z .svn),
* pracujesz u siebie na pc commitujac, a potem zbiorczy commit idzie na macierzysty serwer (wkurzało mnie w robocie jak spr log a tam pierdyliard commitow i ktory jest tym ktorego szukam),
* łatwość pracowania z gałęziami i system na nie zorientowany (a nie jak w svn, branch to tylko taka proteza copy)
Dotąd korzystałem z SVN-a, ale w ostatnich miesiącach przerzuciłem się na Gita. Powód to duża elastyczność, łatwość pracy z gałęziami oraz dzielenia się kodem. W sumie jedyne, czego mi brakuje, to odpowiednik svn:externals, ale z tego, co zdążyłem wyczytać, da się to nieźle zasymulować poprzez podmoduły (submodules). Nawet słabe wsparcie ze strony NetBeans mogę wybaczyć, bo z konsolowego interfejsu korzysta się wygodnie.
Do netbeans-a jest plugin ale nie oficjalny. Ale co powiecie o innych systemach kontroli?
Pod wpływem wątku spróbowałem zabawy z gitem. Nawet całkiem fajny. Najbardziej podoba mi się:
- intuicyjność składni - już nie trzeba ciągle zerkać do manuala, żeby zrobić coś bardziej nietypowego od commita
- patent z brakiem ukrytych folderów jest dobry - już kilka razy udało mi się wysłać przez ftp te ukryte foldery .svn przez nieuwagę
- praca z gałęziami jest banalnie prosta w porównaniu ze składnią z svn'a
Co mnie trochę "zadziwia" i na razie nie wiem czy to dobrze czy źle:
- rozproszenie - jakoś naturalniej czułem się z centralnym serwerem, choć z drugiej strony ma to swoje plusy
@athabus: w GITcie nadal możesz mieć centralny serwer, do którego wszyscy wysyłają zmiany.
Tak zdaję sobie z tego sprawę. Po prostu tutaj jest inna "metodologia" pracy - każdy working directory to również repozytorium. Trochę dziwne wrażenie po przyzwyczajeniach wyniesionych z svn.
Podobnie mam problemy z przyzwyczajeniem się do "stagingowania" - ciągle trzeba mieć to z tyłu głowy.
Właśnie czytam sobie książkę w wolnych chwilach i pewne rzeczy mi się rozjaśniają bo po przeczytaniu tutoriala nie wszystko było jasne.
http://whygitisbetterthanx.com
Również polecam gita, ratuje życie w wielu przypadkach :-)
ja dziś sobie git'a zaprzęgłem do pracy z svn'em, bardzo fajna rzecz i to w standardzie
To ja polece Mercuriala, moim zdaniem ma lepsze wsparcie pod windowsem niż Git. Jak ktoś chce w pigułce o zaletach rozproszonego systemu to http://hginit.com. To w domu, bo w pracy dalej rządzi SVN.
A ja zapytam tak. Co mi po systemie rozproszonym jeżeli np użytkownicy z którymi współpracuje nie mają globalnego ip?
stawiasz serwer do ktorego commitują, albo commitują bezpośrednio do Ciebie (jesli masz zew. IP) rozproszone da sie uzywac jak scentralizowane, np ja synchronizuje lapa ze stacjonarka przez moj serwer
http://pl.wikipedia.org/wiki/Git_%28oprogramowanie%29
Historia tłumaczy dlaczego GIT, sam ostatnio przeniosłem się na gita i jestem zadowolony.
A instalowałeś może gitosisa na swoim serwerze? Bo ja mam z tym nadal cholerne problemy.
Nie, nie bawiłem się w to.
apropos instalacji GITa na serwerze,
jak czytam w http://progit.org/book/pl/ch4-1.html GIT może wykorzystywać do połączenia protokół SSH, gdzie w tym przypadku repo jest po prostu katalogiem,
i nie jest wymagana żadna instalacja GIta na serwerze tylko możliwość dostępu przez SSH?
Inaczej, robię mały projekt z drugim programistą i nie potrzebuje nie wiadomo jakiego zarządzania
i wygląda to tak, że u siebie mam GITa (na PC) a na www tylko katalog z repo po SSH, i wtedy nie musze miec zainstalowanego GITa na serwerze
tak to wygląda z tego co wyczytałem, ale jeszcze nie sprawdzałem
Wybrałem oczywiście GIT-a z jednego powodu. Lokalne Branche.
Zacząłem pracować na nich w momencie gdy zauważylem, że robienie wielu rzeczy na jednym branchu jest trudno i łatwo o bałagan. Lokalne branche ratują nam tyłek.
SVN-owe branche działały za wolno i sprawiały czasem problemy no i jak tu ktoś powiedział, jest to SYMULACJA branchy - zgodzę się.
HG (Mercurial) - jak się dowiedziałem, że "lokalny" branch trzeba wysłać przy pushu NAWET jeżeli jest on nieaktywny to przełączyłem się na chwilę w tryb leminga, ponieważ nie byłem w stanie zrozumieć tej "głupoty".
GIT - branche obsługuje się bardzo łatwo (git branch, git checkout, git merge) i masz wszystko czego potrzebujesz.
Dodatkowo można sobie postawić GITOLITE na swoim VPS-ie, dedyku i masz serwer centralny z uprawnieniami. Nawet na windowsie klieni zainstalował się bez problemu choć nie obeszło się bez pomocy TortoiseGIT przy klonowaniu repozytoriów (żeby ustawić klucze prywatne).
A ja chciałem polecić mały "artykuł": http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/.
Nie używałem jeszcze żadnego z wyżej wymienionych, nie potrzebowałem - pracuję jak james bond - sam, a jeżeli już to pomoc działa na osobnych frontach nie kolidujących z moimi piszgrołami (nowy wyraz ). Niestety (a właściwie stety) zaczynam pracę w teamie i to skłoniło mnie to przeglądania stron o dvcs etc. Poprawiam swoje stanowisko pracy, wymieniam dreamwavera na netbeans'a + mercurial - lepiej mi się z tym pracuje (zaczyna), ale nie wiadomo czy środowiska nie zmienię w krótkim czasie - zależy od teamu i demokratycznego wyboru (na razie mercurial rządzi).
Za mercurial+bitbucket przemawia fakt, że jest tańszy. Fakt github to nie jest wielka kasa, ale drażni mnie np. to, że trzeba płacić za prywatne repozytoria? Nie chodzi o to, że ktoś mi "ukradnie" mój kod... Chciałbym go "ukryć" przed jego ukończeniem, a pokazać dopiero dojrzały owoc.
edit: Wiem, że można postawić np. gitolite - nie w tym sęk, ale serwer też kosztuje .
edit 2:
Co do zalet systemu kontroli wersji 100% się zgadzam...
Dotychczas uważałem, że posiadanie 5ciu kopii jednego projektu (2 stare, jedna świeża + 1 aktualnie poprawiana) wystarczą - Boże ile ja razy kląłem :/, a raz nawet podmieniłem świeży skrypt starym (wtedy dotworzyłem kolejną kopię...) - ale tak jak Ty myślałem, że:
Więc jedyne słuszne rozwiązanie to praca na obu systemach i wybranie tego "właściwego". Zacznę to robić póki nie jest "za późno".
Ale jak na razie mercurial.
Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)