SVN tutorial

Odpowiedz Nowy wątek
2014-12-17 11:13
0

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)

Pozostało 580 znaków

2014-12-17 11:23
0

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

Jeśli chcesz pomocy, NIE pisz na priva, ale zadaj dobre pytanie na forum.

Pozostało 580 znaków

2014-12-17 11:36
0

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 ;)

Pozostało 580 znaków

2014-12-17 11:39
1

@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

edytowany 1x, ostatnio: fasadin, 2014-12-17 11:39
to svn robi diffy na plikach binarnych też? nie wiedziałem. - dzek69 2014-12-17 13:39
http://stackoverflow.com/ques[...]ff-file-marked-as-binary-type Ale ogolnie wszystko raczej jest przechowywane jako text (psd byl tylko przykladem ktory mi przyszedl do glowy) - fasadin 2014-12-17 13:41
Git też ma możliwość robienia binarnych diffów. Poza tym jest mnóstwo tooli do przechowywania i wersjonowania danych binarnych razem z gitem. - hauleth 2015-01-07 12:18

Pozostało 580 znaków

2014-12-17 12:13
m.
0

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...

tak wiem, ale myslalem ze ktos juz szukal cos takiego i ma cos ktos na poleceniu - fasadin 2014-12-17 12:14

Pozostało 580 znaków

2014-12-17 13:14
0

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.

dlatego szukam tutoriala wlasnie zeby mogl sam sobie rozwiazac konflikty. Jakis szybki guideline. Nie chce mi sie tego tlumaczyc wszystkiego :( Mam duzo wazniejsze rzeczy do roboty, dlatego szukam jakiegos tutoriala. Ale chyba jednak mu wytlumacze... - fasadin 2014-12-17 13:18

Pozostało 580 znaków

2014-12-17 15:48
0
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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Pokaż pozostałe 18 komentarzy
Jedyny tutorial Git jaki znam to ten: http://git-scm.com/book/pl/v1 - somekind 2014-12-17 21:01
I taki link w poście powinien pojawić się pod pytaniem kończąc wątek :) @fasadin - wołam, gdybyś nie śledził flejmu w komentarzach :) - Marooned 2014-12-17 21:06
@Marooned, ale on szukał tutoriala dla SVN :D - Wizzie 2014-12-17 21:38
@Marooned ale ja potrzebuje do svn. nie moge przeniesc sie na gita. Ale linka dla siebie zapisze (nie lubie gita, wole hg mimo ze to prawie to samo na hg mi sie latwiej pracuje) - fasadin 2014-12-17 22:05
@Wizzie lol.. za bardzo się wkręciłem hehe ;) no chodziło o analogiczny link, o! [wybrnąłem] - Marooned 2014-12-18 10:02

Pozostało 580 znaków

2014-12-17 21:25
3

@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.


"HUMAN BEINGS MAKE LIFE SO INTERESTING. DO YOU KNOW, THAT IN A UNIVERSE SO FULL OF WONDERS, THEY HAVE MANAGED TO INVENT BOREDOM."
Pokaż pozostałe 3 komentarze
Ładny post. Co do szybkości SVN to nigdy nie miałem żadnych zastrzeżeń. Wszystko szybko działa, a że on sobie coś tam pod maską wylicza to mnie to nie interesuje. - MiL 2014-12-18 11:23
Albo masz małe projekty, albo mało commitów, albo siedzisz blisko serwera. - somekind 2014-12-18 11:24
Ale szybkość gita i svna jest taka sama [no, zbliżona] zakładając, że porównujemy svn commit i git push. Nikt o zdrowych zmysłach nie porównuje svn commit do git commit, tak jak nikt nie porównuje Javy i JavaScriptu. - Marooned 2014-12-18 12:48
Commit SVN to modyfikacja pliku, więc nowy wpis różnicowy. Jak na jakimś pliku miałeś 100 commitów, to wyznaczenie jego najnowszej wersji wymaga 100 obliczeń tej różnicy. W Gicie nie ma ich w ogóle. - somekind 2014-12-18 12:58
A to nie tak, że wysyłany jest tylko diff? Tak czy siak, commit/push są zbliżone, bo wąskim gardłem jest połączenie z serwerem. Nam niedawno przenieśli repo na tokijski amazon i jest taki dramat, że ciśniemy szefa o powrót. - Marooned 2014-12-18 13:26

Pozostało 580 znaków

2014-12-17 21:48
adruab
0

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 ;)

Pozostało 580 znaków

2014-12-17 23:25
the real mućka
0
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).

Używanie SVN jest powodem żeby nie przyjąć pracy? No proszę cię. - MiL 2014-12-18 11:25

Pozostało 580 znaków

2014-12-17 23:47
the real mućka
0

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.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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