SVN tutorial

Poleca ktos tutorial tak jakby
"SVN w pigulce"

Jezyk angielski najlepiej. Rumunski tez moze byc :D, ale lepiej angielski (polski nie moze byc, bo to nie dla mnie)

ucznie się SVN-a jest troszkę bezsensu. To jest rozwiązanie na wymarciu. Ta umiejętność jest konieczna jedynie w dwóch wypadkach (w zasadzie w jednym):

• jeśli się pracuje ze starymi developerami, którzy nie mają ochoty przesiadać się na DVCS (Hg lub Git)
• jakiś pracuje się nad starym dużym projekt i nikomu nie chce się go przenieść do git-a

Ale chcesz się go uczyć, czy potrzebujesz do czegoś? Bo jak nie jest to konieczne, to lepszy moim zdaniem jest Git. Zresztą w drugim przypadku też możliwa jest migracja z SVN na Git ;)

@MarekR22 @Sarrus to jest dla artysty. wersjonowanie plikow psd (czy innych ciezkich plikow ktore sie zmieniaja ciagle) ktore sie zmieniaja dla hg czy gita bedzie meczarnia (repo puchnie strasznie szybko) dlatego uzywamy do tego svna. (w przyszlosci do tego ma sluzyc dropbox)

Niestety przy ostatnim razie mial problemy z dodawaniem i komitowaniem rzeczy. Pokazac mu za bardzo nie moge bo ta osoba pracuje zdalnie

Technologii niestety nie wybieram. Znam jako tako svna. Ale nie chce mi sie pisac tutoriala do tego wiec myslalem ze moze gdzies jest cos takiego

Przecież svn jest tak stary jak świat, nie łatwiej wpisać w google coś w rodzaju `svn simple tutorial' i wyświetli się tego masa, nawet dla gościa nieinformatyka do przełknięcia? Przecież góra co będzie potrzebował, to dwa czy trzy polecenia... Nie musi być svn-owym guru...

Wydaje mi się, że bez szkolenia się nie obejdzie. Taki grafik opanuje svna, ale dostanie konfilkt na twarz i nie będzie wiedział co z tym zrobić. U mnie tak było przynajmniej. Narzędzia są - skype pozwala na udostępnianie pulpitu, a TeamViewer pozwala na wspólne klikanie na komputerze.

MarekR22 napisał(a):

ucznie się SVN-a jest troszkę bezsensu. To jest rozwiązanie na wymarciu. Ta umiejętność jest konieczna jedynie w dwóch wypadkach (w zasadzie w jednym):

• jeśli się pracuje ze starymi developerami, którzy nie mają ochoty przesiadać się na DVCS (Hg lub Git)
• jakiś pracuje się nad starym dużym projekt i nikomu nie chce się go przenieść do git-a

Albo jak klient wymaga SVN i płaci Ci za jego używanie.

Starzy deweloperzy, czyli ludzie po trzydziestce, bo oni generalnie nie są zdolni do uczenia się niczego nowego. Można to zauważyć nawet na tym forum.

@MiL - tak w skrócie - Git jest systemem rozproszonym, więc właściwie całą historię masz lokalnie. Nie potrzebujesz połączenia sieciowego do jej przeglądania, do cofnięcia się do poprzednio działającej wersji jakiegoś pliku, itp. Jest to po prostu szybsze.
Git jest szybszy także z tego powodu, że w rewizjach przechowuje całe pliki, a nie różnice. W przypadku cofania się do którejś rewizji, nie musi niczego wyliczać, po prostu przywraca pliki. To jest znacznie szybsze (tym szybsze w porównaniu z SVN, im więcej zmian w danym pliku było). Wada - repozytoria Git zajmują nieco więcej miejsca.
W Gicie gałąź jest po prostu zbiorem rewizji, a nie kopią katalogu repozytorium jak w SVN, więc możesz pracować na zasadzie branch-per-feature, czyli tworzysz gałąź dla każdego zadania, implementujesz je, a następnie integrujesz z główną gałęzią. Dzięki temu, w swojej gałęzi dla zadania możesz robić commit nawet co każdą linijkę (wszystko lokalnie, czyli nie wymaga sieci, więc jest błyskawiczne). Gdy skończysz swoje zdanie, zrobisz merge (albo rebase), dopiero wtedy wysyłasz je do zdalnego repozytorium.
Z tego wynika, że jeśli chcesz używać Gita jak SVNa, czyli mieć jedną gałąź, to masz dwa razy więcej roboty w Git niż w SVN (za każdym razem najpierw commit, a potem push). Jeśli natomiast używasz Gita tak, jak został zaprojektowany, to roboty masz niewiele więcej, za to mogąc robić częste commity, nie tracisz tyle czasu na implementację od nowa, gdy w trakcie pracy coś zepsujesz.
Warto też mieć na uwadze, że tworzenie gałęzi jest operacją lokalną, a ponieważ gałąź jest wskaźnikiem na rewizję, więc jej tworzenie jest błyskawiczne w przeciwieństwie do SVN, który robi kopię całego katalogu.
Co do konfiliktów przy merge - Git jest prostym narzędziem, które śledzi wyłącznie zmiany w treści plików, zaś SVN śledzi historię zmian katalogów. Co za tym idzie, jeśli w tym samym pliku, ale w dwóch gałęziach dodasz taką samą linijkę, SVN wykryje konflikt (bo to inne rewizje w historii, nieważne, że treść taka sama), a Git nie (bo to taka sama treść). Dlatego merge w Git jest prostsze - bo z definicji jest mniej konfliktów.

Najtrudniejsze, co trzeba zrozumieć, to to, że SVN jest bardziej podobny do serwera FTP, tzn. Twoja gałąź trunk na dysku jest po prostu kopią gałęzi trunk z serwera. To jest proste i intuicyjne. W Git jest to bardziej skomplikowane, bo Twój lokalny master, master Twojego kolegi i master na zdalnym serwerze, to są trzy różne gałęzie. Dlatego właśnie, gdy pobierasz zmiany ze zdalnego repozytorium do siebie, to musisz je zintegrować ze swoją lokalną gałęzią. Co za tym idzie, Git nie pozwoli Ci pobrać zmian ze zdalnego repozytorium, jeśli u siebie masz jakieś nie zakommitowane pliki, bo mógłbyś w ten sposób stracić swoją pracę.

Co mi jeszcze przychodzi na myśl - w Gicie jest plik gitignore, w którym definiuje się listę ignorowanych plików i katalogów. Działają maski, więc można sobie wpisać np. *.dll albo /**/Debug i wszystkie te pliki w całym repozytorium będą ignorowane. W przypadku SVN trzeba to ustawiać oddzielnie dla każdego podkatalogu w repozytorium.

Kiedyś wpadłem na coś takiego https://layervault.com
Nie jest to co prawda darmowe i nie korzystałem z tego więc nie wiem jak się sprawuj, ale może się przyda ;)

somekind napisał(a):

w rewizjach przechowuje całe pliki, a nie różnice. W przypadku cofania się do którejś rewizji, nie musi niczego wyliczać, po prostu przywraca pliki.

Mylisz sie: http://git-scm.com/book/en/v2/Git-Internals-Packfiles,

somekind napisał(a):

W Gicie gałąź jest po prostu zbiorem rewizji

W gicie galaz jest tylko i wylacznie 'wskaznikiem' ktory ma nazwe na pewien commit, i ten wskaznik sie przemieszcza wraz z utworzeniem nowego commita na danym branchu. Usuniecie galezi jest operacja bardzo latwa - usuniecie wskaznika. Utworzenie brancha - utworzenie wskaznika. Itp.

somekind napisał(a):

za to mogąc robić częste commity, nie tracisz tyle czasu na implementację od nowa, gdy w trakcie pracy coś zepsujesz.

Swieta prawda, nie wyobrazam sobie inaczej pracy. Robie commity bardzo czesto, kazdy pomysl ma nowego commita, jesli sie nie uda to go wywalam i wracam do poprzedniej wersji. Na koniec robie squasha - pakuje wiele commitow w jednego, ladnego, banalna operacja. I wszystko dzieje sie lokalnie, nikt inny nie widzi moich smieci jesli ja tego nie chce; inni widza piekny, spojny, od poczatku do konca przemyslany kod.

somekind napisał(a):

W przypadku SVN trzeba to ustawiać oddzielnie dla każdego podkatalogu w repozytorium.

Dodam tylko ze i w gicie tak mozna (w hg zdaje sie ze nie), i przydaje sie to zeby gitignory byly mniejsze i latwiejsze, i nie ignorowaly przypadkiem za duzo lub troszke za malo...

Ale ogolnie niezly post. Wprowadzenie jakiegos DVCS (w 2 firmach wprowadzilem mercuriala/hg, w obecnej nasz zespol byl pierwszy ktory uzywa tylko git) jest pierwsza rzecza ktory bym zrobil. Przymus korzystania ze starych narzedzi typu svn jest dla mnie argumentem aby zmienic projekt, nie przyjac pracy itp.

Aby zrozumiec podstawy DVCS, polecam na poczatek ten tutorial Joela Spolsky'ego: http://hginit.com/. Co prawda nie o git lecz o hg, ale zasady dokladnie takie same (na tym poziomie zaawansowania).

Dla tych co 'nie moga' przeniesc sie na gita i musza twrac w svn, jest git-svn - uzywa sie lokalnie jak gita, a pushe sa gitowymi pushami. Podobnie pulle, tylko w druga strone. Ponoc wielu uwaza, ze git jest znacznie lepszym klientem svn niz svn ;d Ogolnie to nie ma zadnej przeszkody zeby nie sprobowac czegos nowego, tylko beton.

the real mućka napisał(a):

Mylisz sie: http://git-scm.com/book/en/v2/Git-Internals-Packfiles,

O ile dobrze rozumiem, to tu chodzi o jakąś opcjonalną możliwość oszczędzania przestrzeni przez Gita, która nie musi być zastosowana. Mi zaś chodziło o podstawy podstaw: http://git-scm.com/book/en/v2/Getting-Started-Git-Basics#Snapshots,-Not-Differences

W gicie galaz jest tylko i wylacznie 'wskaznikiem' ktory ma nazwe na pewien commit, i ten wskaznik sie przemieszcza wraz z utworzeniem nowego commita na danym branchu. Usuniecie galezi jest operacja bardzo latwa - usuniecie wskaznika. Utworzenie brancha - utworzenie wskaznika. Itp.

Tak, oczywiście masz rację, to jest wskaźnik. Tylko wiem już z doświadczenia, że ta definicja nic nie powie komuś przyzwyczajonemu do SVN. Ja chciałem przekazać jak to wygląda od strony użytkownika - w SVN jest katalog, w Gicie gałąź wygląda bardziej jak wirtualny zbiór commitów.

the real mućka napisał(a):

Dla tych co 'nie moga' przeniesc sie na gita i musza twrac w svn, jest git-svn - uzywa sie lokalnie jak gita, a pushe sa gitowymi pushami. Podobnie pulle, tylko w druga strone.

Tylko nie ma push i pull, lecz dcommit i svn rebase.

fasadin napisał(a):

Poleca ktos tutorial tak jakby
"SVN w pigulce"
Nie wiem, czy w pigułce, ale rzuć okiem na http://svnbook.red-bean.com/en/1.1/index.html

fasadin napisał(a):

Niestety przy ostatnim razie mial problemy z dodawaniem i komitowaniem rzeczy. Pokazac mu za bardzo nie moge bo ta osoba pracuje zdalnie

Tak się zastanawiam... czy w takim przypadku nie będzie wam łatwiej kazać mu zainstalować svn-a/git-a i dać mu gotowe pliku z jakimś skryptem robiące to co ma zrobić (bash, bat, etc...). Jak sądzę ma zrobić tylko grafikę i przesłać na serwer, skąd możecie to sobie pobrać. Niech sobie kliknie po zrobieniu zmian w rysunku np. zapisz.bat i pójdzie. Skoro nie poradził sobie z "dodawaniem i komitowaniem" to nawet w svn-ie coś w końcu spaprze.

sprawa juz rozwiazana. A jeszcze raz powtorze.

Nie mam mozliwosci zmiany technologii. Jakbym mial to bym nie pracowal w unity tylko np w Unreal Engine

I dodatkowo git NIE JEST dobry dla duzych plikow ktore sie zmieniaja. Repo by bylo wielkie bardzo szybko