Dokumentację umiem czytać, ale nie widzę praktycznego zastosowania tego polecenia. Czy ktoś, kto ma doświadczenie z SVN mógłby wyjaśnić, po co to jest?
Nie bardzo rozumiem pytanie. Służy do przepięcia się na innego brancha po prostu.
W jakim sensie przepięcia? W SVN każdy branch jest przecież oddzielnym katalogiem, w każdym z nich mogę edytować/updatować i commitować pliki niezależnie. Co daje to "przepięcie brancha"?
http://svnbook.red-bean.com/en/1.6/svn.branchmerge.switchwc.html
tl;dr: switch działa szybciej od gołego checkouta bo ciągnie zmiany w repozytorium a nie wszytko od nowa
Czyli używa się go tylko po to, żeby nie robić checkouta każdej gałęzi?
Co trzeba trzymać w repozytorium, żeby ta szybkość miała znaczenie? Logi aplikacji? :P
Jeśli projekt jest wielki, a pracujemy tylko na jednej branchy, to może być bez sensu checkoutowanie całego repo.
Nie polecam switchowania. Jak się klient svn pogubi to potrafi puścić część plików na jednego brancha, a część na drugiego. Sprzątanie tego burdlu chwilę trwało, a commitujący miał minę jak irański sędzia
Odpowiednik git checkout branch_name
tyle tylko, że spartolony po całości. Sprawdza się w przypadku małych projektów. W przypadku dużych checkoutujesz i tak poszczególne branche by uniknąć sajgonu o którym wspomniał @Sarrus
Azarien napisał(a):
Jeśli projekt jest wielki, a pracujemy tylko na jednej branchy, to może być bez sensu checkoutowanie całego repo.
No jeśli pracuję na jednej gałęzi, to checkoutuję tylko jedną i żaden switch do tego nie jest potrzebny.
Switch dziala szybciej od zwyklego checkouta kiedy struktura katalogow projektu jest podobna - przynajmniej tak z moich obserwacji wynika. Jednak jak wspomnieli przedmówcy SVN tak potrafi czasem namieszać w plikach, że kompletnie sie zrazilem do tego narzedzia
Zazwyczaj robię checkout trunka do /project/. i pracując zawsze się switch'uję - na nowego brancha i znów na trunka. Taki schemat mi odpowiada, choć przy ogromnych różnicach (np. dorzucony jakiś potężny vendor) switch trochę zajmie. Lubię mieć pliki projektu w jego katalogu głównym.
Wiadomo, że Git jest git, ale bez przesady ze straszeniem ludzi SVN-em. Od lat nigdy nie miałem sytuacji, żeby nie commitowało się dokładnie to, co miało się commitnąć wg svn status. Na pewno błędów da się uniknąć, szczególnie mając wiedzę i nie korzystając z graficznych GUI pokroju popularnego "Żółwika" (na windzie zyskał chyba status standardu :d).
Ja na localu rzeczywiście checkoutuję osobne branche, ale switch
przydaje się jak mamy swoją dev maszynę i szef chce zobaczyć postępy prac, które robimy w branchu. Switch i dev ma już nowy kod. Oczywiście zakładając brak zmian w DB, bo wtedy to już nie takie hop siup.
Marooned napisał(a):
Oczywiście zakładając brak zmian w DB, bo wtedy to już nie takie hop siup.
Dlatego lepiej mieć oddzielne maszyny (albo przynajmniej oddzielne instancje bazy i aplikacji) dla różnych branchy.
Piszesz o tym jak jest lepiej, a ja Ci piszę do czego to można wykorzystać, jak warunki nieco Cię ograniczają. switch
jest szybszy od konfiguracji i restartu apache
;-)
Marooned napisał(a):
Piszesz o tym jak jest lepiej, a ja Ci piszę do czego to można wykorzystać, jak warunki nieco Cię ograniczają.
switch
jest szybszy od konfiguracji i restartuapache
;-)
Pomocne są też serwery odpalane z linii poleceń, serwujące aktualny katalog pod jakimś portem localhosta (php -S, rake etc).
Wspólną bazę pozwala utrzymać system migracji, ale też bywają z tym problemy.
Ogolnie, switch jest przydatny do deployowania prostych(?) aplikacji, ot taka stara szkola zanim pojawil sie pierdyliard hipsterskich narzedzi :S
Taki przyklad:
masz projekt o kryptonimie dupa, repo znajduje sie pod adresem:
http://source/svn/dupa
i teraz mamy linie developerska, trunk:
http://source/svn/dupa/trunk
mamy branch stage
http://source/svn/dupa/branches/dupa-1.2
no i mamy tag z wersja projektu:
http://source/svn/dupa/tags/dupa-1.2.3
projekt zostal zrolowany na produkcji za pomoca zwyklego checkouta:
svn co http://source/svn/dupa/tags/dupa-1.2.3
teraz banda napalonych programistow przyp1erdolila troche kodu i o swicie powstal nowy tag:
http://source/svn/dupa/tags/dupa-1.2.4
no i zeby zmienic wersje na produkcji wystarczy switch:
svn switch http://source/svn/dupa/dupa-1.2.4
plus i minus tego rozwiazania jest taki ze jest proste jak jebanie, nadpisuje jedynie delte i revert mozna zrobic drugim switchem
Zarejestruj się i dołącz do największej społeczności programistów w Polsce.
Otrzymaj wsparcie, dziel się wiedzą i rozwijaj swoje umiejętności z najlepszymi.