On 2012-12-01 22:48, e...@g...com wrote:
> W git ogolnie pracuje sie lokalnie. To pozwala na wiele rzeczy,
> ktore w klient-serwer nie sa mozliwe. Mozna m.in. robic swoje
> branche, potem je bezpiecznie usuwac, czesto nawet tak sie
> robi i to na 5 minut lub dzien. Ma sie tez lokalnie historie.

Tak z ciekawości, bo to często podnoszny argument za gitem. Co jest
lepszego w tworzeniu branchy lokalnie vs tworzeniu branchy w repo? Bo ja
widzę okropną wadę: Ciężko się takim branchem podzielić z kolegą. Repo
tworzy (i usuwa, ale po co usuwac?) branche w sekundy. Zaznaczam że
mówimy o kontekście: repo jest lokalnie w sieci.

do góry

W dniu niedziela, 2 grudnia 2012 09:39:40 UTC+1 użytkownik Sebastian Biały napisał:
> On 2012-12-01 22:48, e...@g...com wrote:

> Tak z ciekawości, bo to często podnoszny argument za gitem. Co jest
> lepszego w tworzeniu branchy lokalnie vs tworzeniu branchy w repo? Bo ja
> widzę okropną wadę: Ciężko się takim branchem podzielić z kolegą. Repo
> tworzy (i usuwa, ale po co usuwac?) branche w sekundy. Zaznaczam że
> mówimy o kontekście: repo jest lokalnie w sieci.

Powiedzmy, ze rozwijasz dwie funkcjonalnosci w danym kodzie, i robisz
poprawki.

W git robi sie do tego 3 branche, lokalnie. Nawet z niezapisanymi
zmianami w jednym z nich jak przychodzi mail "potrzebujemy tu
natychmiast poprawke", robi sie "git stash; git checkout poprawki",
robi poprawke, po czym "commit" "git chechout func1; git stash pop" i
pracuje dalej jakby nigdy nic.

Po rozwinieciu dwoch funkcjonalnosci robi sie merge do brancha z
glownego repo nowej funkcjonalnosci i push, a potem najczesciej
kasuje brancha tej funkcjonalnosci.

To wszystko strasznie by zasmiecalo wspolne repozytorium i repozytoria
wszystkich, ktorzy ciagna ze wspolnego do siebie.

Podzielenie sie branchem nie jest trudne, w sytuacji po wojnie
nuklearnej moznaby zzipowac caly katalog .git i wyslac, a ten
sobie lokalnie zrobi pull. Ale mozna tez robic branche w glownym repo,
a potem usunac po merge (lub po odrzuceniu zmian).

--
Edek

do góry

On 2012-12-02 14:55, e...@g...com wrote:
> Powiedzmy, ze rozwijasz dwie funkcjonalnosci w danym kodzie, i robisz
> poprawki.
> W git robi sie do tego 3 branche, lokalnie.

W svn robi się do tego 2 branche w repo.

> Nawet z niezapisanymi
> zmianami w jednym z nich

svn commit, svn switch na trunk, svn merge i svn switch na drugą.
Prywanie mam dodatkowy katalog z trunkiem do błyskawicznych merge, ale
to niekonieczne, switche trwają sekundy.

> a potem najczesciej
> kasuje brancha tej funkcjonalnosci.

Po co? Czego się wstydzić? Kodu czy bałaganu w branchach?

> To wszystko strasznie by zasmiecalo wspolne repozytorium i repozytoria
> wszystkich, ktorzy ciagna ze wspolnego do siebie.

Odwrotnie. Kolega X pracował nad ficzerem. Niestety zachorował i nie
przyszedł do roboty. *Ktokolwiek* moze wziąść jego brancha i ciągnąc
dalej. To zaleta:

a) branchy w repo
b) kultury i higieny pracy

Nie naciskam, ale scenariusz który przedstawiasz jeszcze bardziej
nastawia mnie "anty" do lokalnych branchy i filozofii pracy gita. Sa
cholernie niebezpieczne (gdzie on miał te pliki?) i nic nie dają ponad
to co daje svn repo (robi się tak samo szybko). W scenaruszu gdy
pracujesz lokalnie z repo i w dodatku w grupie git nie daje *nic*.

do góry

W dniu niedziela, 2 grudnia 2012 17:19:20 UTC+1 użytkownik Sebastian Biały napisał:
> On 2012-12-02 14:55, e...@g...com wrote:
> > Powiedzmy, ze rozwijasz dwie funkcjonalnosci w danym kodzie, i robisz
> > poprawki.
> > W git robi sie do tego 3 branche, lokalnie.

> W svn robi się do tego 2 branche w repo.

Pod warunkiem, ze masz polaczenie do serwera, git tego nie wymaga. Po drugie,
nie pamietam jak to jest w svn jak sie pomylisz (np. wybranchujesz nie
z tego commita). Da sie to cofnac?

> > Nawet z niezapisanymi
> > zmianami w jednym z nich

> svn commit, svn switch na trunk, svn merge i svn switch na drugą.
> Prywanie mam dodatkowy katalog z trunkiem do błyskawicznych merge, ale
> to niekonieczne, switche trwają sekundy.

Ja wole robic commit, ktory jest jakos kompletny. Od przerwania w polowie
linijki jest stash. Po drugie merge wolalbym robic juz nie tylko kompletncyh
rzeczy, ale sprawdzonych, w sensie ze dzialaja. Nie widze powodu, zeby
jedne nieskonczone funkcjonalnosci wplywaly na rozwoj innych.

> > a potem najczesciej
> > kasuje brancha tej funkcjonalnosci.
> Po co? Czego się wstydzić? Kodu czy bałaganu w branchach?

Nie bardzo rozumiem. Kod zostaje, jest zmergowany. A o jakim balaganie
mowa to nie wiem.

> > To wszystko strasznie by zasmiecalo wspolne repozytorium i repozytoria
> > wszystkich, ktorzy ciagna ze wspolnego do siebie.

> Odwrotnie. Kolega X pracował nad ficzerem. Niestety zachorował i nie
> przyszedł do roboty. *Ktokolwiek* moze wziąść jego brancha i ciągnąc
> dalej. To zaleta:
> a) branchy w repo
> b) kultury i higieny pracy

No tak, uzywajacy git-a nie choruja ;)

> Nie naciskam, ale scenariusz który przedstawiasz jeszcze bardziej
> nastawia mnie "anty" do lokalnych branchy i filozofii pracy gita. Sa
> cholernie niebezpieczne (gdzie on miał te pliki?) i nic nie dają ponad
> to co daje svn repo (robi się tak samo szybko). W scenaruszu gdy
> pracujesz lokalnie z repo i w dodatku w grupie git nie daje *nic*.

Jak to "gdzie on mial te pliki"? W repo, jak zawsze.

Co tam kto lubi. Mi git daje wiele mozliwosci, ktorych starszy svn nie ma.

--
Edek

do góry

On 2012-12-02 17:35, e...@g...com wrote:
>>> Powiedzmy, ze rozwijasz dwie funkcjonalnosci w danym kodzie, i robisz
>>> poprawki.
>>> W git robi sie do tego 3 branche, lokalnie.
>> W svn robi się do tego 2 branche w repo.
> Pod warunkiem, ze masz polaczenie do serwera, git tego nie wymaga.

To było założenie podane 2 posty wcześniej.

> Po drugie,
> nie pamietam jak to jest w svn jak sie pomylisz (np. wybranchujesz nie
> z tego commita). Da sie to cofnac?

W svn wszystko da się cofnąć. Ale od razu kasować? Wybranchowanie nie
zajmuje *nic* w repo.

>> svn commit, svn switch na trunk, svn merge i svn switch na drugą.
>> Prywanie mam dodatkowy katalog z trunkiem do błyskawicznych merge, ale
>> to niekonieczne, switche trwają sekundy.
> Ja wole robic commit, ktory jest jakos kompletny.

Ja również utrzymuje commit w stanie przynajmniej kompilująctym się. Ale
... prawdę mówić to pracuje jeszcze inaczej: mam tyle katalogów na dysku
ile otwartych branchy. Czas przełączenia się wynosi więc 0, a bywa że
mam otwartych kilka środowisk na róznych branchach.

> Po drugie merge wolalbym robic juz nie tylko kompletncyh
> rzeczy, ale sprawdzonych, w sensie ze dzialaja.

I w czym to przeszkadza? Przecież przyszedł kierownik i kazał
wcommitować. Widocznie było gotowe.

> Nie widze powodu, zeby
> jedne nieskonczone funkcjonalnosci wplywaly na rozwoj innych.

I nie ma.

>> Po co? Czego się wstydzić? Kodu czy bałaganu w branchach?
> Nie bardzo rozumiem. Kod zostaje, jest zmergowany. A o jakim balaganie
> mowa to nie wiem.

"Kazik, pamiętasz może tego Wojtka co pracował w zeszłym roku? On coś
robił na branchu, ale nie dał rady. Weź i zerknij do czego to się
nadaje. Tu masz brancha".

Czasem kod *NIE* zostaje zmergowany. Czasem pośrednie commity (np.
odrzucone rozwiązanie) warto ponownie obejrzeć po miesiącu. Ogólnie nie
potrafie zrozumieć potrzeby usuwania branchy z repo, choć z tą
przypadłością ciągle się spotykam w róznych grupach. Przy czym czesto
wyjasnieniem jest aby nie zajmowały miejsca (svn) :)

>> Nie naciskam, ale scenariusz który przedstawiasz jeszcze bardziej
>> nastawia mnie "anty" do lokalnych branchy i filozofii pracy gita. Sa
>> cholernie niebezpieczne (gdzie on miał te pliki?) i nic nie dają ponad
>> to co daje svn repo (robi się tak samo szybko). W scenaruszu gdy
>> pracujesz lokalnie z repo i w dodatku w grupie git nie daje *nic*.
> Jak to "gdzie on mial te pliki"? W repo, jak zawsze.

Ktorym? Lokalnym? O k...

do góry

W dniu niedziela, 2 grudnia 2012 18:02:24 UTC+1 użytkownik Sebastian Biały napisał:
> On 2012-12-02 17:35, e...@g...com wrote:
> >>> Powiedzmy, ze rozwijasz dwie funkcjonalnosci w danym kodzie, i robisz
> >>> poprawki.
> >>> W git robi sie do tego 3 branche, lokalnie.
> >> W svn robi się do tego 2 branche w repo.
> > Pod warunkiem, ze masz polaczenie do serwera, git tego nie wymaga.

> To było założenie podane 2 posty wcześniej.

Mam laptopa i czasami nie mam neta i nie musze miec - a moge robic
dokladnie te same operacje, co w svn przy polaczeniu.

> > Po drugie,
> > nie pamietam jak to jest w svn jak sie pomylisz (np. wybranchujesz ni
> > z tego commita). Da sie to cofnac?

> W svn wszystko da się cofnąć. Ale od razu kasować? Wybranchowanie nie
> zajmuje *nic* w repo.

Oprocz tego, ze zostaje widoczny branch (wiesz, to pbyla pomylka i
tak zostalo).

> >> svn commit, svn switch na trunk, svn merge i svn switch na drugą
> >> Prywanie mam dodatkowy katalog z trunkiem do błyskawicznych merge, al
> >> to niekonieczne, switche trwają sekundy.
> > Ja wole robic commit, ktory jest jakos kompletny.

> Ja również utrzymuje commit w stanie przynajmniej kompilująctym się. Ale
> ... prawdę mówić to pracuje jeszcze inaczej: mam tyle katalogów na dysku
> ile otwartych branchy. Czas przełączenia się wynosi więc 0, a bywa że
> mam otwartych kilka środowisk na róznych branchach.

No ale widzisz, w svn robisz zmiany, potem kompilujesz i wypada puscic testy
i dopiero commit. W git juz jak sie kompiluje sprawdzam cale zmiany
i robie commit. Jak sie nie skompiluje lub nie dziala, poprawiam juz
zrobiony commit ("--amend") - nikt nigdy nie zobaczy schrzanionego commita.
Z SVN byl to odwieczny problem, przy 100 deweloperach czesto zdarzaly
sie nie udane buildy, bo ktos sie pomylil.

Takich drobnych roznic jest masa.

> >> Po co? Czego się wstydzić? Kodu czy bałaganu w branchach?
> > Nie bardzo rozumiem. Kod zostaje, jest zmergowany. A o jakim balaganie
> > mowa to nie wiem.

> "Kazik, pamiętasz może tego Wojtka co pracował w zeszłym roku? On coś
> robił na branchu, ale nie dał rady. Weź i zerknij do czego to się
> nadaje. Tu masz brancha".

> Czasem kod *NIE* zostaje zmergowany. Czasem pośrednie commity (np.
> odrzucone rozwiązanie) warto ponownie obejrzeć po miesiącu. Ogólnie nie
> potrafie zrozumieć potrzeby usuwania branchy z repo, choć z tą
> przypadłością ciągle się spotykam w róznych grupach. Przy czym czesto
> wyjasnieniem jest aby nie zajmowały miejsca (svn) :)

No ale git nie pozwoli ci usunac takiego brancha - na tym polega cale
bezpieczenstwo, jezeli zmiany z brancha sa tylko na branchu, git wymaga
opcji, ktora mowi "tak, chce sie bezpowrotnie pozbyc tych zmian".

Usuwa sie branche, ktore sa juz zmergowane zupelnie w innym celu. W
przeciwienstwie do svn zostaje pelna historia commitow z brancha - daty,
autorzy, opisy itd. . Taki usuwany branch staje sie historia tylko jako
branch, ktory juz nie bedzie rozwijany, bo wszystko zostalo zrobione
- pelna informacja na temat historii zawsze zostaje.

Branche sie robi w git czesto nie po to, zeby mialy miec dlugie zycie,
sa inne mozliwosci i przez to inne praktyki. Nie ma wiekszego sensu
stosowanie do oceny tego zwyczajow z svn.

> >> Nie naciskam, ale scenariusz który przedstawiasz jeszcze bardziej
> >> nastawia mnie "anty" do lokalnych branchy i filozofii pracy gita. Sa
> >> cholernie niebezpieczne (gdzie on miał te pliki?) i nic nie dają ponad
> >> to co daje svn repo (robi się tak samo szybko). W scenaruszu gdy
> >> pracujesz lokalnie z repo i w dodatku w grupie git nie daje *nic*.
> > Jak to "gdzie on mial te pliki"? W repo, jak zawsze.

> Ktorym? Lokalnym? O k...

A dlaczego niby "o k..."? I tak robie backup. Zmieniam katalog nadysk sieciowy
i robie przed wyjsciem z pracy "git clone" - robi to w minute kopie 1:1
wszystkiego co mam lokalnie przy milionach linii kodu i mnostwie wygenerowanych
plikow, dodatkowo w bezpieczny sposob. Wiec zostaje i laptop i kopia sieciowa,
nawet gdybym mial odejsc z pracy rzucajac wszystko momentalnie w p..u.

Z takiegj kopii repo mozna korzystac dokladnie tak samo jak z glownego,
lokalna czy nie lokalna nic tu zmienia.

--
Edek

do góry

On 2012-12-02 18:36, e...@g...com wrote:
> Mam laptopa i czasami nie mam neta i nie musze miec - a moge robic
> dokladnie te same operacje, co w svn przy polaczeniu.

Tak, ale masz specyfczną sytuację gdzie SVN się nie sprawdza. Dlatego
podałem zalożenie, i nie tyczy ono Ciebie ale autora wątku. Jesli
pracujesz bez repo to SVN odpada i koniec dyskusji. Ja nie chce Cie
przekonać do lepszości SVNa tylko szukam odpowiedzi jak git mógłby
wzbogacić mój warsztat pracy. Chwilowo mimo ideologicznego a czasem i
religijnego nastawienia wielu gitowców nie potafie znaleźc nic co by mi
pomogło w pracy.

>> W svn wszystko da się cofnąć. Ale od razu kasować? Wybranchowanie nie
>> zajmuje *nic* w repo.
> Oprocz tego, ze zostaje widoczny branch (wiesz, to pbyla pomylka i
> tak zostalo).

Jak widzisz jedynym powodem kasowania branchy jest zwykły wstyd. Popsuło
się? I co z tego? Jesli masz porządek w branchach dodatkowy nic nie
przeszkadza.

> No ale widzisz, w svn robisz zmiany, potem kompilujesz i wypada puscic testy
> i dopiero commit. W git juz jak sie kompiluje sprawdzam cale zmiany
> i robie commit. Jak sie nie skompiluje lub nie dziala, poprawiam juz
> zrobiony commit ("--amend") - nikt nigdy nie zobaczy schrzanionego commita.

Dlaczego ma nie zobaczyć? Albo rewertujesz albo commitujesz fixa. Nie
rozumie, dlaczego wśród gitowców jest tak powszechne oszukiwanie (tu nie
bylo żadnego commita!). Praca z repo z rewizjami wymaga pewnej higieny
która wychodzi na zdrowie.

> Z SVN byl to odwieczny problem, przy 100 deweloperach czesto zdarzaly
> sie nie udane buildy, bo ktos sie pomylil.

Zaryzykuje że to nie ilośc developerow ale poziom komplikacji kodu ma
większe znaczenie. A "nieudane" buildy to jest możliwe w kazdej sytuacji
bez względu na kontrole wersji. Na szczęscie procesy zapewniające
integralnośc buildu dają się łatwo automatyzować (o ile nie ma się
burdelu ...).

> Usuwa sie branche, ktore sa juz zmergowane zupelnie w innym celu. W
> przeciwienstwie do svn zostaje pelna historia commitow z brancha - daty,
> autorzy, opisy itd.

Tak samo w svn.

> . Taki usuwany branch staje sie historia

*DOKŁADNIE* o to chodzi. Przypadek z tego tygodnia: musiałem wygrzebać
branch mniej więcej z zeszłego roku. Był. Mialem tam niedokończoną
implementację która była teraz jak znalazł.

>>> Jak to "gdzie on mial te pliki"? W repo, jak zawsze.
>> Ktorym? Lokalnym? O k...
> A dlaczego niby "o k..."? I tak robie backup. Zmieniam katalog nadysk sieciowy
> i robie przed wyjsciem z pracy "git clone" - robi to w minute kopie 1:1
> wszystkiego co mam lokalnie przy milionach linii kodu i mnostwie wygenerowanych
> plikow, dodatkowo w bezpieczny sposob.

Zupełnie jak svn commit?

Dalej nie jestem przekonany, twoje argumenty nie pokazują żadnej
lepszosci gita nad svnem w przypadku o który chodziło (jak się okazuje)
autorowi wątku. Przyznaje, że jestem gotowy przejśc na gita pod
warunkiem natrafienia na jeden killer-feature vs svn, bo drobnostki w
svn są upierdliwe.

do góry

W dniu niedziela, 2 grudnia 2012 19:05:59 UTC+1 użytkownik Sebastian Biały napisał:
> On 2012-12-02 18:36, e...@g...com wrote:

> >> W svn wszystko da się cofnąć. Ale od razu kasować? Wybranchowanie nie
> >> zajmuje *nic* w repo.
> > Oprocz tego, ze zostaje widoczny branch (wiesz, to pbyla pomylka i
> > tak zostalo).

> Jak widzisz jedynym powodem kasowania branchy jest zwykły wstyd. Popsuło
> się? I co z tego? Jesli masz porządek w branchach dodatkowy nic nie
> przeszkadza.

Tu nie chodzi o wstyd. Mi nawet nie jest wstyd, jak popsuje wszsytkim builda
i testy - bo to sie zdarza w dowolnym systemie kontroli wersji.

Chodzi - mi przynajmniej - o latwosc i szybkosc korzystania. Nie lubie,
jak mnie repozytorium meczy, jak musze mega uwazac, wole zajac sie praca
nad kodem.

> > No ale widzisz, w svn robisz zmiany, potem kompilujesz i wypada puscic testy
> > i dopiero commit. W git juz jak sie kompiluje sprawdzam cale zmian
> > i robie commit. Jak sie nie skompiluje lub nie dziala, poprawiam juz
> > zrobiony commit ("--amend") - nikt nigdy nie zobaczy schrzanionego commita.

> Dlaczego ma nie zobaczyć? Albo rewertujesz albo commitujesz fixa. Nie
> rozumie, dlaczego wśród gitowców jest tak powszechne oszukiwanie (tu nie
> bylo żadnego commita!). Praca z repo z rewizjami wymaga pewnej higieny
> która wychodzi na zdrowie.

Nie wiem skad pomysl, ze w git nie ma "higieny".

Nie ma tez oszukiwania: wszystko co sie wypchnie do wspolnego repo zostaje.
Natomiast wygodnie jest lokalnie poprawiac zanim sie wypchnie. "Amend" jest
nawet w GUI, bo jest wygodne - po co komu w historii zepsuty commit i
revert lub poprawka nic nie wnoszaca, moze byc jeden dobry commit. Jako
ze amend sluzy do poprawki jednego commita, da sie tez poprawic commity
pod spodem, ale za pomoca kilku komend - znowu, o ile wciaz sa lokalne.
Nawet da sie odzyskac usuniete niby na zawsze rzeczy lub makabrycznie
schrzaniony merge. Mi sie podoba to, ze nie musze tak mega uwazac i ze
moge bezkarnie robic bledy, bo ja czasem robie bledy. Jak te bledy moge
poprawic zanim sa na master (cvs trunk) lub nawet na wspolnym branchu,
to z tego korzystam.

> > Z SVN byl to odwieczny problem, przy 100 deweloperach czesto zdarzaly
> > sie nie udane buildy, bo ktos sie pomylil.
>
> Zaryzykuje że to nie ilośc developerow ale poziom komplikacji kodu ma
> większe znaczenie. A "nieudane" buildy to jest możliwe w kazdej sytuacji
> bez względu na kontrole wersji. Na szczęscie procesy zapewniające
> integralnośc buildu dają się łatwo automatyzować (o ile nie ma się
> burdelu ...).

U nas to sie zdarza, budujemy wiele wersji i czasem jedna czy dwie sie
nie zbuduja. Za duzo czasu wymagaloby budowanie wszystkiego lokalnie
dla sprawdzenia. Ale i tak jest latwiej niz z svn.

> > Usuwa sie branche, ktore sa juz zmergowane zupelnie w innym celu. W
> > przeciwienstwie do svn zostaje pelna historia commitow z brancha - daty,
> > autorzy, opisy itd.

> Tak samo w svn.

No wlasnie nie tak samo, to jedna z glownych zalet gita.

> > . Taki usuwany branch staje sie historia
>
> *DOKŁADNIE* o to chodzi. Przypadek z tego tygodnia: musiałem wygrzebać
> branch mniej więcej z zeszłego roku. Był. Mialem tam niedokończoną
> implementację która była teraz jak znalazł.

No ale niedokonczonych sie nie usuwa, po co.

> >>> Jak to "gdzie on mial te pliki"? W repo, jak zawsze.
> >> Ktorym? Lokalnym? O k...
> > A dlaczego niby "o k..."? I tak robie backup. Zmieniam katalog nadysk sieciowy
> > i robie przed wyjsciem z pracy "git clone" - robi to w minute kopie 1:1
> > wszystkiego co mam lokalnie przy milionach linii kodu i mnostwie wygenerowanych
> > plikow, dodatkowo w bezpieczny sposob.

> Zupełnie jak svn commit?

Ano nie, nie jak svn commit.

> Dalej nie jestem przekonany, twoje argumenty nie pokazują żadnej
> lepszosci gita nad svnem w przypadku o który chodziło (jak się okazuje)
> autorowi wątku. Przyznaje, że jestem gotowy przejśc na gita pod
> warunkiem natrafienia na jeden killer-feature vs svn, bo drobnostki w
> svn są upierdliwe.

OP mowil, ze na poczatku chce pracowac lokalnie. Git wymaga stworzenia
katalogu i jednej komendy. Stawianie repo svn wymaga znacznie wiecej czasu.

EOT, nie sadze zeby ta dyskusja kogokolwiek juz interesowala.
--
Edek

do góry

On 2012-12-02 19:48, e...@g...com wrote:
> W dniu niedziela, 2 grudnia 2012 19:05:59 UTC+1 użytkownik Sebastian Biały napisał:
>> On 2012-12-02 18:36, e...@g...com wrote:
>
>
> OP mowil, ze na poczatku chce pracowac lokalnie. Git wymaga stworzenia
> katalogu i jednej komendy. Stawianie repo svn wymaga znacznie wiecej czasu.
>
> EOT, nie sadze zeby ta dyskusja kogokolwiek juz interesowala.
>
Mnie interesuje, podnosicie ciekawe argumenty i obaj macie racje. :-).

Pozdrawiam

Marek

do góry

On 2012-12-02, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2012-12-02 17:35, e...@g...com wrote:
>>>> Powiedzmy, ze rozwijasz dwie funkcjonalnosci w danym kodzie, i robisz
>>>> poprawki.
>>>> W git robi sie do tego 3 branche, lokalnie.
>>> W svn robi się do tego 2 branche w repo.
>> Pod warunkiem, ze masz polaczenie do serwera, git tego nie wymaga.
>
> To było założenie podane 2 posty wcześniej.

SVN jest przeraźliwie wolny, jeśli masz a) więcej niż kilkunastu
programistów, b) kilka bardziej obciążonych commitami repozytoriów,
c) serwer SVN dalej niż 100ms od siebie. Praca odłączona jest dużo
wygodniejszą strategią w takich przypadkach.

>> Po drugie,
>> nie pamietam jak to jest w svn jak sie pomylisz (np. wybranchujesz nie
>> z tego commita). Da sie to cofnac?
>
> W svn wszystko da się cofnąć. Ale od razu kasować? Wybranchowanie nie
> zajmuje *nic* w repo.

Nieprawda że nie zajmuje nic, ale prawda, że jest bardzo tanie.

--
Secunia non olet.
Stanislaw Klekot

do góry