GoldenLine
Zaloguj się
Patryk Mikel

Patryk Mikel Student,
Politechnika Śląska
w Gliwicach

Temat: SVN - jego używanie

Właśnie od kilku dni zacząłem używać SVN do własnych projektów, aby nauczyć się go w praktyce, a także, żeby nie tworzyć kilku kopi zapasowych danego katalogu z projektem jak zaczynam pisać nową funkcjonalność.

I teraz mam kilka pytań odnośnie tego systemu, które mnie nurtują:

- Jak często robicie commit? Tzn. po napisaniu jednej funkcji czy może jednej funkcjonalności? Bo właśnie nie wiem jak często to robić i chyba robie za często. Dodanie nowego pliku, dodanie nowej funkcjonalności (po każdej takiej operacji robie commit)

- Jak zacząć korzystać ze struktury -trunk, -branches, -tags? Tzn. o co w tym chodzi i po jakich zmianach umieszczać tam swój projekt i czy robiąc to przez komendę "svn copy" czy może jakąś inną?
Link do wypowiedziLink
Robert B.

Robert B. Web Development
Manager

Temat: SVN - jego używanie

Patryk Mikel:
Właśnie od kilku dni zacząłem używać SVN do własnych projektów, aby nauczyć się go w praktyce, a także, żeby nie tworzyć kilku kopi zapasowych danego katalogu z projektem jak zaczynam pisać nową funkcjonalność.

I teraz mam kilka pytań odnośnie tego systemu, które mnie nurtują:

- Jak często robicie commit? Tzn. po napisaniu jednej funkcji czy może jednej funkcjonalności? Bo właśnie nie wiem jak często to robić i chyba robie za często. Dodanie nowego pliku, dodanie nowej funkcjonalności (po każdej takiej operacji robie commit)
Tak często jak tylko uważasz to za stosowne - generalna zasada to po opracowaniu jakiegoś kawałka funkcjonalności. W praktyce średni co 1h, nie rzadziej niż raz dziennie.

- Jak zacząć korzystać ze struktury -trunk, -branches, -tags? Tzn. o co w tym chodzi i po jakich zmianach umieszczać tam swój projekt i czy robiąc to przez komendę "svn copy" czy może jakąś inną?
Zasady są bardzo proste:
- /trunk - najbardziej aktualna wersja którą chciałbyś się wymienić z innymi programistami lub wrzucić na serwer testowy
- /branches/nazwa/ - coś nad czym pracujesz, ale jeszcze nie chcesz tego udostępnić innym, lub nie wiesz, czy powinno to być udostępnione. Z reguły brancha robisz jeśli chcesz mieć kontrolę wersji na czymś co jeszcze nie działa tak jak powinno
- /tags/nazwa/ - 'relis' :-) klepnięta wersja, która już nie będzie zmieniana,np.: do wrzucenia na produkcję.

Używanie tego jest bardzo proste:
- tworzysz repo
- tworzysz w nim katalogi (trunk, tags, branches)
- do trunk wrzucasz swój projekt (np.: ścieżki będą takie: /trunk/lib, /trunk/app, /trunk/config)
- gałęzie tworzysz jak tylko ich potrzebujesz, czyli np.: /branches/test1/lib/

Command line w tej chwili nie pamiętam - z regóły posiłkuję się Eclipse i subclipse:-)
Link do wypowiedziLink
Piotr Zarzycki

Piotr Zarzycki Open Source
Developer

Temat: SVN - jego używanie

Witam.

Jeżeli chodzi o commit - myślę, że powinieneś wypracowac samodzielnie jakoś tą kwestię. Ja również commit-uje gdy zakończe określoną funkcjonalnośc, ale zazwyczaj jest to coś większego w danym projekcie. Obowiązkowo także robie commit na koniec dnia i kieruję się zasadą, że na serwerze umieszczam wersję kompilującą się - czyli taką która jest w stanie się uruchomic. - Nawet jeżeli dana funkcjonalnośc nie jest skończona.

Co do struktury katalogów - kiedyś natrafiłem na fajny wpis na blogu może to Ci rozjaśni nieco temat:
Sposób pracy na Subversion (branche, tagi etc)
Polecam Ci także blog Macieja Aniserowicza, który sporo pisał o svn-ie.

Pozdrawiam.
Link do wypowiedziLink
Piotr Zarzycki

Piotr Zarzycki Open Source
Developer

Temat: SVN - jego używanie

No i się spóźniłem ;)
Link do wypowiedziLink

konto usunięte

Temat: SVN - jego używanie

Patryk Mikel:
- Jak zacząć korzystać ze struktury -trunk, -branches, -tags? Tzn. o co w tym chodzi i po jakich zmianach umieszczać tam swój projekt i czy robiąc to przez komendę "svn copy" czy może jakąś inną?

Warto poczytac o systemie kontroli wersji GIT i jego merge'ach. Chociaz w SVN dziala troche inaczej, lektura na pewno pozwoli Ci lepiej zrozumiec idee branchy i tagow.
Link do wypowiedziLink

konto usunięte

Temat: SVN - jego używanie

Zastanów się, skoro dopiero w to wchodzisz, czy nie warto iść w kierunku GIT-a.
Aktualnie jest to najmodniejszy system kontroli wersji do www.
Nie znam jego zalet czy wad, ale ludzie go sobie chwalą jako następce SVN-a.
Link do wypowiedziLink
Marek Wywiał

Marek Wywiał Programista,
administrator,
instruktor

Temat: SVN - jego używanie

W svn pracowaliśmy ok 2 lata i trzymaliśmy tam kilkadziesiąt projektów + jeden główny spory.

Żeby ogarnąć pracę w SVN używaliśmy svnauto:
* http://www.contextualdevelopment.com/labs/sva/

automatyzuje on pracę na branchach rel/bug/ i tagach wprowadzając porządek. Zostaje tylko problem SVN'a jako zcentralizowanego systemy kontroli, że pobranie każdej informacji o branchach/wydaniach to kilka wywołań przez net, co zajmowało czas.

Ostatecznie przez ok. miesiąc testowaliśmy pracę z git przy pomocy git-svn (lokalnie git, zdalnie wysyłany do svn'a) na grupie testowej i potem oficjalnie przeszliśmy na GIT i jest git :)

Branche/tagi są wbudowane, nie symulowanie katalogami + svnauto. Sprawdzanie tagów/wydań log/blame/itp wszystko odbywa się szybko i lokalnie.

Co do svnato, autor na koniec dodał skrypt migrujący strukturę z svn+svnauto na git i zaprzestał rozwoju :)

Ogólnie polecam pracę z GIT zamiast z SVN. Nadal mamy centralne repozytorium zarządzane poprzez gitosis, do którego wszyscy wysyłają zmiany.
Commit robimy jak najczęściej do lokalnych branchy, które potem mergujemy jako jeden commit do głównej linii (w ten sposób mogę rozwijać funkcjolność przez kilka dni, a w master mieć jeden commit, który jako patch mogę przenieść nawet na środowisko produkcyjne)
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: SVN - jego używanie

daruj sobie svna najszybciej jak potrafisz, git zmiata go w każdej kwestii. 1,5 roku pracowałem z svnem, prawie rok pracuję z gitem, naprawdę różnica w możliwościach i szybkości jest ogromna. z resztą, gdyby tak nie było, nie byłoby github.com, a do kernela linuksa używali by czegoś innego :-)
jak już połapiesz podstawy, to polecam książkę progit (dostępna za darmo w sieci). o takich funkcjach jak na przykład rebase --interactive, cherry-pick, bisect, stash w svnie można tylko pomarzyć :-)Wojciech Sznapka edytował(a) ten post dnia 22.02.10 o godzinie 01:12
Link do wypowiedziLink
Patryk Mikel

Patryk Mikel Student,
Politechnika Śląska
w Gliwicach

Temat: SVN - jego używanie

Chętnie się pouczę GITa, ale nie rozumiem rozproszonych systemów kontroli wersji. W SVN to jest tak, że jest jedno repozytorium na serwerze i każdy programista pobiera sobie kopie roboczą do siebie na kompa. No i to rozumiem dobrze. Ale za chiny nie mogę zrozumieć jak działają DVCS i jak wygląda dostęp do plików tam.
Link do wypowiedziLink
Marcin P.

Marcin P. Zakamuflowany
programista

Temat: SVN - jego używanie

Patryk Mikel:
Chętnie się pouczę GITa, ale nie rozumiem rozproszonych systemów kontroli wersji. W SVN to jest tak, że jest jedno repozytorium na serwerze i każdy programista pobiera sobie kopie roboczą do siebie na kompa. No i to rozumiem dobrze. Ale za chiny nie mogę zrozumieć jak działają DVCS i jak wygląda dostęp do plików tam.
Najpierw wykonujesz commit do swojego lokalnego repozytorium, a gdy stwierdzisz że wszystko jest okej(cały moduł gotowy, dana funkcjonalność, koniec dnia etc..) to wysyłasz commit do serwera w sieci.
Link do wypowiedziLink
Rafał T.

Rafał T. Programista C#, ASP
.NET, T-SQL

Temat: SVN - jego używanie

Osobiście też używam SVN, ale mam kilka problemów które w sieci też występują, także zastanawiam się nad przejściem i czytając jestem coraz bardziej pewny że to zrobię.
Kilka informacji o GIT można znaleść na:

http://www.maciejaniserowicz.com/default.aspx

Pozdrawiam
Link do wypowiedziLink
Marcin K.

Marcin K. Programowanie jest
moim powołaniem,
Alleluja

Temat: SVN - jego używanie

Polecam także konkurencyjne rozwiązanie jak: Mercurial

Trochę informacji: http://pl.wikipedia.org/wiki/Mercurial
GUI: http://tortoisehg.bitbucket.org/

System jest świetny, działamy na nim od roku. Podobnie jak GIT jest rozproszony. Co w nim jest takiego fajnego? wsparcie dla większości systemów (Windows, Linux, Mac Os....)

Zastanawialiśmy się nad GIT, system super! jedynie dręczyło Nas wsparcie dla innych systemów niż LINUX(poprawki wychodzą strasznie późno). Obecnie jest wersja 1.7.0 dla Linux, 1.6.5.1 dla Windows, a tak naprawdę różnica między tymi wersjami jest kolosalna ;)

Słuszny wybór na dziś to: GIT, Mercurial, Bazaar
Link do wypowiedziLink
Patryk Mikel

Patryk Mikel Student,
Politechnika Śląska
w Gliwicach

Temat: SVN - jego używanie

Czyli w gicie ogólnie chodzi o to, że ma się dwa repozytoria: jedne lokalne na swoim kompie i drugie zewnętrzne na serwerze. Każdy user w ciągu dnia wysyła commity do repozytoria lokalnego i na końcu dnia wysyła commit do repozytoria zewnętrznego tak jak już w SVN tak? Dobrze to rozumiem? A jeśli dobrze, to czy tylko tym się GIT różni od SVN?
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: SVN - jego używanie

Patryk Mikel:
Czyli w gicie ogólnie chodzi o to, że ma się dwa repozytoria: jedne lokalne na swoim kompie i drugie zewnętrzne na serwerze. Każdy user w ciągu dnia wysyła commity do repozytoria lokalnego i na końcu dnia wysyła commit do repozytoria zewnętrznego tak jak już w SVN tak? Dobrze to rozumiem? A jeśli dobrze, to czy tylko tym się GIT różni od SVN?

mniej więcej. Scott Chacon w swoich prezentacjach często mówi o "Blessed Repository", czyli takie jakby centralne repo jak w svnie. Jest to repo np. lidera projektu. On do swojego repo pulluje od kierownika frontendowców i kierownika backendowców, a ci dwaj od swoich podwładnych. Dzięki temu tworzy się sieć zaufania, struktura hierarchiczna - łatwiej zapanować nad kodem w dużych projektach (patrz kernel linuksa).
Do tego można mieć repozytoria na serwerze produkcyjnym i testowym, gdzie tylko wpychamy (git push test-serwer), a na nim hookiem post-recieve automatycznie się resetuje i dzięki temu masz najprostszy i najskuteczniejszy sposób na deploy'owanie aplikacji.

Odpowiadając na pytanie: czym różni się git w przypadku gdy i tak wysyłamy commity do do centralnego repo? Tym, że to co masz w swoim repozytorium lokalnym to twój skarb :-) Możesz tam mieć 150 branchy (w ticket-workflow nazywanych np ticketami z traca: 2032-naprawa-buga) a w masterze tylko to, co chciałbyś żeby widział świat. Poza tym jeśli lubisz często commitować, to możesz robić to w branchu, a do mastera ("oficjalnego brancha" mergować z opcją --squash (w skrócie spłaszcza wszystkie commity w jeden z własny komentarzem commita), lub rebase'ować branche poboczne interaktywnie na master, czyli po zakończonym zadaniu grupować commity w spójne changesety i następnie zmergować do odpowiedniego brancha (master)).

Najważniejsze, że wszystko robisz offline, jedyne operacje dostępu do sieci to git pull, git push i git clone (tego używa się tylko raz). Dzięki temu działa to niesamowicie szybko (żaden VCS nie przebija szybkością Gita).
Link do wypowiedziLink
Patryk Mikel

Patryk Mikel Student,
Politechnika Śląska
w Gliwicach

Temat: SVN - jego używanie

Hmm "pulluje"? Czyli co? Hmm czyli widzę GIT ma więcej opcji niż commit i checkout SVNa, tak?
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: SVN - jego używanie

git pull <remote> to odpowiednik svn update - pobiera zmiany z zdalnego repo i uaktualnia twoje repo, ewentualnie rozwiązuje konflikty, lub pozostawia tobie do rozwiązania
git push <remote> jest operacją odwrotną do pull, "wpycha" twoje commity do zdalnego repo. Można by go porównać trochę do svn commit, ale tylko pod względem wysłania zmian do zdalnego repozytorium.

git pull zmienia pliki w working tree (bezpośredni na dysku), git push wpycha tylko do indeksu repozytorium, nie modyfikując plików bezpośrednio na dysku. Git push nie powinien być IMHO używany, jeśli na repozytorium zdalnym pracuje człowiek, wtedy powinieneś poprosić go, aby pullował (pobrał) od ciebie zmiany. Tak działa github - nie można pushować komuś do repo, można wysłać mu "pull request" - info o tym, że coś porobiłeś na klonie jego repozytorum i jeśli ma ochotę, żeby to włączył do głównego nurtu.

btw. github jest kopalnią dobrych praktyk jeśli chodzi o gita, używają go najwięksi (częściowo symfony, jquery , facebook itd).
Link do wypowiedziLink
Patryk Mikel

Patryk Mikel Student,
Politechnika Śląska
w Gliwicach

Temat: SVN - jego używanie

A mam jeszcze już chyba ostatnie pytanie. Bo czytając wiele tekstów, dużo osób mówi, że plik z projektem ma w swoim katalogu, a później tylko synchronizuje zmiany na środowisko produkcyjne. Możecie powiedzieć jak to wygląda?
Link do wypowiedziLink
Jarosław R.

Jarosław R. Pragmatyczny
Idealista

Temat: SVN - jego używanie

Podepnę się pod powyższe pytanie.

Z reguły moje środowisko pracy to właśnie IDE, sprzęgnięte z SVNem na laptopie z konfiguracją LAMP gdzie każdy projekt ma swoją wirtualną domenę, no i płatny serwer produkcyjny.

Jakie są sposoby, metody, zwyczaje na to by po zmianach w projekcie lokalnie, po commicie do repozytorium jednocześnie te zmiany wprowadzić na serwer produkcyjny??

W serwisie xp-dev.com jest opcja WebHooka, który wyśle POSTem pod wskazany adres zakodowaną JSONem informację o każdym commicie.

Czy może używacie jeszcze dodatkowych narzędzi jak rsync czy winscp?
Link do wypowiedziLink

konto usunięte

Temat: SVN - jego używanie

Najlepiej, jeżeli na produkcję nie wrzuca się plików "ręcznie" (np. przez FTPa), tylko poprzez (automatyczne, lub ręczne) zrobienie svn up. Może być też inne (moim zdaniem bezpieczniejsze) rozwiązanie - svn up robi się na serwerze testowym. Po poprawnych testach, wrzuca się pliki na produkcję za pomocą rsync.

Oczywiście powyzsze etapy można zautomatyzować.Krzysztof Rakowski edytował(a) ten post dnia 01.03.10 o godzinie 14:11
Link do wypowiedziLink
Wojciech Sznapka

Wojciech Sznapka CTO @ STS Zakłady
Bukmacherskie

Temat: SVN - jego używanie

masz repo gita lokalnie
sshujesz na produkcję
robisz git init
lokalnie robisz git remote add produkcja ssh://user@serwer.com/home/user/folder_z_pustym_repo_gita
lokalnie robisz git push produkcja
na produkcji: git reset HEAD --hard albo hooka na post-recieve
Link do wypowiedziLink
« Wróć do tematów
Odpowiedz

Podobne tematy





Wyślij zaproszenie do
Anuluj