Do czego służy switch w SVN?

0

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?

0

Nie bardzo rozumiem pytanie. Służy do przepięcia się na innego brancha po prostu.

0

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"?

0

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

0

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

0

Jeśli projekt jest wielki, a pracujemy tylko na jednej branchy, to może być bez sensu checkoutowanie całego repo.

2

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

2

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

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

0

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

0

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

0

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.

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

0

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

0
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 restartu apache ;-)

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.

2

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

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