W dniu 04.10.2010 23:31, Sebastian Biały pisze:
> Miało być EOT :/
>
> On 2010-10-04 22:41, Lech Lorens wrote:
>> - Git jest znacznie szybszy niż SVN (nawet działający po sieci lokalnej)
>> - wycheckoutowanie kilku GB projektu naprawdę odbywa się szybciej,
>> jeśli odbywa się bez dostępu do sieci (w szczególności jeśli tą siecią
>> jest internet),
>
> a) autor wątku ma raczej mały projekt (zgaduje)
>
Co mogłoby być niezłym miejscem na naukę obsługi systemu kontroli wersji.

> Teraz już EOT definitywnie-definitywnie. Pozdrawiam gitowców.
Trochę Cię nie rozumiem. Nie tak dawno temu wyśmiewałeś beton
programistów uC, którzy robią niestworzone konstrukcje w C zamiast
skorzystać z wygody jaką daje C++. Teraz prezentujesz imo taki sam beton
tyle, że w odniesieniu do systemu kontroli wersji. Upierasz się, że
SVN(/C - niepotrzebne skreślić ;) ) przecież wystarcza, mimo, że małym
kosztem można dostać 'sporo więcej".

A co do samego wątku - git na początek to imo zbyt dużo, ale
hg/darcs/bazar imo byłyby ok.
Jedną z zalet rozproszonego systemu kontroli wersji jest to, że nie jest
potrzebny pełnoprawny serwer - patche można nawet i mailami przesyłać,
czy na jakiegoś ograniczonego ftp wrzucać. Poza tym dają zaletę używania
systemu kontroli wersji bez konieczności ciągłego połączenia z siecią i
bez robienia masy gałęzi w repo w czasie developowania. Z moich
obserwacji wynika, że SVN zwłaszcza na początku sprawia, że commitowane
są duże porcje zmian a w efekcie zniechęca do systemów kontroli wersji -
"bo i tak w nich nie widać, to może i być tar ze źródłami na stronie".

Po wieloletnich przygodach z darcs/hg/(trochę)git w te wakacje zmuszony
byłem używać SVN. Był to wystarczający bodziec do nauczenia się git-svn.

--
Pozdrawiam
Michoo

do góry

W dniu 2010-10-06 00:41, Stachu 'Dozzie' K. pisze:
> To znaczy masz tam możliwość włączenia WebDAV-a czy nie? Bo ja nie
> jestem nawet ich klientem.

Słowo "WebDAV" nigdzie w panelu sterowania nie występuje.
Jest coś co się nazywa "Web Disk" czyli dostęp zapis odczyt poprzez
http, widzę toto w moich miejscach sieciowych.
Udało mi się nawet zrobić "git clone" na to.
Muszę jeszcze trochę poczytać, to może się uda.

--
Pozdrawiam,
Andrzej

do góry

On 2010-10-05, Andrzej W. <awa_wp.a_to_wytnij> wrote:
> W dniu 2010-10-06 00:41, Stachu 'Dozzie' K. pisze:
>> To znaczy masz tam możliwość włączenia WebDAV-a czy nie? Bo ja nie
>> jestem nawet ich klientem.
>
> Słowo "WebDAV" nigdzie w panelu sterowania nie występuje.
> Jest coś co się nazywa "Web Disk" czyli dostęp zapis odczyt poprzez
> http, widzę toto w moich miejscach sieciowych.

To najprawdopodobniej będzie WebDAV.

> Udało mi się nawet zrobić "git clone" na to.
> Muszę jeszcze trochę poczytać, to może się uda.

Jeśli to faktycznie WebDAV, to wystarczy ci taka procedura instalacji
repozytorium:
mkdir nabla
cd nabla
touch empty.txt
git init --bare
git add .
git commit -m Init
git update-server-info
# skopiowanie katalogu nabla do udziału
Reszta to zwykłe `git clone'.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2010-10-06 00:18, Bodek wrote:
> To opiszesz jak wygląda obciążenie twojego serwera, czy dalej będziesz
> wycinał niewygodne fragmenty?

Nie wiem jak wygląda obciążenie *mojego* serwera w domu, raczej jest
mizerne. Ale serwera na którym *pracuje* wygląda na kilkadziesiąt osób i
kilkadziesiąt MB kodu. Działa. Zaskakująco sprawnie.

>> Kto *normalny* robi 100 commitów na godzinę żeby te 45 sek miało śladowe
>> znaczenie ?
> Poczytaj sobie na przykład o metodologii pracy Linusa.

Po co? Przeciez 100 commitów na godzinę jest *bzdurą*.

>> Ty ich nie robisz nawet w gicie.
> Nie, nie widzę powodu dla którego miałbym robić sobie osobne branche
> tylko po to, żeby zacommitować na nie zmianę jednej linijki, a potem
> od razu zmerge'ować do mastera.

Nie potrzebujesz wobec tego branchy. Bo twój branch z kilkunastoma
poprawkami jest tylko zbytkiem bitów. Po prostu edytuj pliki wprost na
trunku.

>> a potem
>> podczas commitowania decydujesz co jest od czego.
> Ale ty pierdzielisz od rzeczy.

Raczej potwarzam zasłyszane:

- Git ma "staging area" - to taka funkcjonalność, która sprawia, że
> > nowy commit tworzą tylko te zmiany, które wskażesz. Możesz zmienić
> > zawartość całego pliku, ale zdecydować się na zacommitowanie zmiany
> > tylko np. w 3 pierwszych linijkach pliku

>> U mnie tworzenie brancha trwa tak krótko ze nie ma sensu sie rozwodzić
>> nad tym dłużej niż 1 sek czasu potrzebnego na jego stworzenie.
> Śmieszne.

Ba, a jakie prawdziwe.

> Nie, chce usunąć commita.

Czyli wymazać historię. Sorry, SVN na tym nie polega. Commit jest
święty. Właśnie po to sa rewizje.

> Dla mnie wartością jest nie tylko sam kod, ale również zapis procesu
> jego powstawania.

W rewizji 12345 była regresja. Nie wiemy jednak dlaczego bo jakiś
miszczu usunął historię a po tygodniu okazało się że ta regresja to
progresja.

> Robiąc burdel w commitach robisz burdel w kodzie, po
> prostu.

To jest historia. Po wykonaniu reverta repozytorimu jest w taki samym
stanie jak przed pierowtym commitem, jedyna róznica to inne numerki. 0
burdelu. Albo pokaż palcem gdzie on jest poza dyskomfortem psychicznym.

>> Ważne że *już* ich nie ma.
> Może w twojej metodyce pracy.

Myslę że w repo.

>>> , a tu kij wie co się dzieje, bo poprzedni programista naczytał
>>> się o wzorcach projektowych
>> Co to ma wspólnego z robieniem branchy?
> A co ma niby mieć?

No własnie pytam co mają wzorce do robienia branchy, przeciez to twój
przykład.

> Daj znać, jak już ustalisz sam ze sobą obowiązujący punkt widzenia.

To ze rozumiesz coś inaczej nie oznacza że inni mają rozdwojenie jaźni.
Moze nalezy czytać między wierszami, coś się domyślić.

>> linie ktorych plików sa tymi wlaściwymi. Sugerujesz ze potrzebujesz
>> podejmowac decyzje co wkomitować w momecie komitowania.
> Tak, potwierdzam. Oczywiście że potrzebuję. Nie wiem tylko co to ma
> wspólnego z tym co sobie ubzdurałeś i mi cały czas wmawiasz.

Powyżej masz cytat.

> Masz moduł A, interfejs B, implementację C. Dodajesz do interfejsu B
> nic nie robiącą metodę wirtualną, którą implementujesz w C, a
> wywołujesz z A. Oczywiście, dopóki nie upewnisz się, że wszystko na
> 100% działa (zmiany w A, B, C są zaimplementowane), nic nie
> commitujesz. Dla porządku, zmiany w B, A, C commitujesz osobno (przy
> podanym porządku commitów zmiany są atomowe). Wytłumacz jak to
> osiągnąć na SVN-ie, przy założeniu że wszystkie zmiany były robione
> tylko w jednym pliku.

Teraz wyjaśnij mi *po* co mam je mergować osobno na trunk (bo na branch
mogę)? Jaki jest cel który uzyskam komitując te pierdoły pojedynczo?
Jaki *rzeczywisty* a nie wymyślony powód sugeruje merge pojedyncze?

(co gorsza twoje pytanie ma odpowiedź w SVN ale chciałbym najpier
zapytać *PO* co).

>> To czego "nie mam" to jest branch i tam sobie moge pieprzyć dowoli.
> Nie możesz, bo branch jest publiczny.

Gówno prawda. Branch to publiczna piaskownica. Mozesz tam wkladać co
chcesz i potem to zlewać, psuć kod, generować dowolne błędy i regresje.
jest rzecza niezrozumiałą po co miałby ktoś to śledzić poza paranoją.

>> Natomiast upublicznianie nazywa się mergowaniem z trunkiem.
> Zupełnie mylisz pojęcia.

Wiec co jest upublicznianiem kodu w/g Ciebie? Commit na brancha? Jeśli
masz paranoje na punkcie podglądania cudzego kodu to można zastosować
prawa dostępu żby nikt Twoich zmian nie oglądał. Dalej nie rozumiem po co.

> Twoja metodyka pracy nie przewiduje przeglądania mailing listy z
> commitami?

Z branchy? Te kilkadziesiąt na godzinę? Sorry, ale nie.

>> Moze po prostu inaczej rozumiemy upublicznianie. ja jako upublicznianie
>> rozumiem wrzucenie w główne źrodła. A to że ktoś na branchu wrzucił
>> sobie zdjęcia porno mało mnie interesuje
> Ciekawe co by na to powiedział klient.

Czepiasz się słów gubiąc przesłanie. Klient nie ma dostepu do branchu.
Kilenta nie obchodzi jak została przygotowany commit. Ważne że podczas
mergowania do trunka jest kompletny, sprawdzony i przetestowany.

>> Dalej zaprzeczasz podstawowej zasadzie istnienia systemów kontroli wersji.
> Która polega na czym? Ta zasada?

Że kazda zmiana jest w historii. Sugerujesz że git moze manipulowac
histrią. To źle bo to nie jest potrzebne.

>>> No dawaj, chętnie posłucham jaki super jest SVN. Też mówię serio.
>> Nie.
> No i tyle w temacie. To SVN-a też nie używałeś?

Przyciąłeś za dużo. Nie będę przekonywał o superowatości SVNa bo to jest
gównaniy system kontroli wersji. Ale git jest gównie gównaniy, a nawet
bardziej w zastosowaniu z którego powstał ten watek.

>> To
>> jakis problem psychiczny że nie chcesz aby ktoś oglądał twoja
>> piaskownicę?
> "zazwyczaj nie mam ochoty oglądac pośrednich wypocin innych."
> A ja nie jestem ekshibicjonistą i nie mam ochoty innym pokazywać moich
> pośrednich wypocin.

Więc to problem czysto psychiczny. Kwestia przełamania się.

>> Ludzie nie mają co robic tylko wymieniają się uwagami jak
>> ktoś cos na branchu spieprzył?
> Ja staram się orientować co się w kodzie dzieje. Bez patrzenia na
> zmiany było by trochę ciężko, ale pewnie mi zaraz powiesz jak to w
> twojej metodyce pracy wygląda.

*Nie* chcesz oglądać zmian na branchach. Interesują Cie zmiany na
trunku. Tam je oglądasz, a jak jesteś rozsądnym człowiekiem to commity
trunkowe są przepuszczane *najpierw* przez code review i pilnowane przez
automatyke do wykrywania regresji.

>> Zauważyleś słowo mediana a nie średnia? Bo pojawiło się nie bez powodu.
> Wytłumacz mi jak to tam działa z tymi merge'ami, bo mi się to w głowie
> nie mieści.

W trunku masz rewizje:

123
150
189
197
230

Robisz switch to revision 189 i sprawdzasz regresje. Nie ma? To robisz
switch do 150 i sprawdzasz. Nie ma? To na 123. Listę rewizji na trunku
svn z przyjemnością wyrzuci jesli go poprosisz.

Informajca z ktorego brancha to pochodzi w SVN jest (od niedawna o ile
pamiętam) ale jest *zbedna* żeby wykonać ta operację.

>>> ROTFL. U ŹRÓDŁA! POPRAWIENIE COMMITU Z BŁĘDEM! ROZUMIESZ?
>> Revert.
> A ty dalej powtarzasz wyuczone hasełka.

Nie, to metodyka pracy z SVN.

>>>>> a nie w późniejszym commicie.
>>> NIE W COMMICIE PÓŹNIEJSZYM!
>> A jakaś to różnica po wykonaniu reverta?
> Taka, że nie jestem badziewiarzem patrzącym się tylko na to co jest na
> masterze/trunku/HEAD i przeszkadza mi szambo w historii projektu.

Szambo tak naprawdę nie istnieje. Nie wpływa na cokolwiek. Jest
przezroczyste. Jesli masz z tym problem to może to jest tylko Twoj problem.

do góry

On 2010-10-06 01:22, Michoo wrote:
> skorzystać z wygody jaką daje C++. Teraz prezentujesz imo taki sam beton
> tyle, że w odniesieniu do systemu kontroli wersji. Upierasz się, że
> SVN(/C - niepotrzebne skreślić ;) ) przecież wystarcza, mimo, że małym
> kosztem można dostać 'sporo więcej".

To sporo więcej nie jest za darmo. Narzędzia wspomagające do gita,
szczególnie klikalne, są o 100 lat za TortoiseSVN. Przynajmniej były rok
temu kiedy usilnie szukalem *czegokolwiek* działającego, ale z chęcią
poczytam co się zmieniło.

SVN jest bardziej intuicyjny do gita. Próg wejscia jest nisko. IDE
zazwyczaj ma go zintegrowanego.

> Jedną z zalet rozproszonego systemu kontroli wersji jest to, że nie jest
> potrzebny pełnoprawny serwer - patche można nawet i mailami przesyłać,
> czy na jakiegoś ograniczonego ftp wrzucać.

Podczas normalnej pracy z gitem ludzie narzekają na to że nie pamiętaja
ktora poprawka z jakiego pliku jest do czego. IMHO jeśli mogę mieć
centralny serwer to wygodniejsze że ktoś pilnuje numerków. Praca bez
serwera ma sens kiedy naprawdę go nie można miec.

> Poza tym dają zaletę używania
> systemu kontroli wersji bez konieczności ciągłego połączenia z siecią i
> bez robienia masy gałęzi w repo w czasie developowania.

Gałęzie są prawie za darmo. Ani nie powiekszają znaczaco repo ani nie
powodują przesyłania danych (a jedynie zmian).

> Z moich
> obserwacji wynika, że SVN zwłaszcza na początku sprawia, że commitowane
> są duże porcje zmian a w efekcie zniechęca do systemów kontroli wersji

Kwestia przecież umiejętności a nie samego systemu kontroli wersji.

do góry

On 2010-10-06, Sebastian Biały <h...@p...onet.pl> wrote:
>>> Kto *normalny* robi 100 commitów na godzinę żeby te 45 sek miało śladowe
>>> znaczenie ?
>> Poczytaj sobie na przykład o metodologii pracy Linusa.

> Po co? Przeciez 100 commitów na godzinę jest *bzdurą*.

"Nie wiem czy to ma sens, ale nie będę czytał czy ma sens, bo nie ma
sensu". A skąd pomysł że to commity przygotowane *przez niego*?

>> Robiąc burdel w commitach robisz burdel w kodzie, po
>> prostu.

> To jest historia. Po wykonaniu reverta repozytorimu jest w taki samym
> stanie jak przed pierowtym commitem, jedyna róznica to inne numerki. 0
> burdelu. Albo pokaż palcem gdzie on jest poza dyskomfortem psychicznym.

Ano tu: commitujesz przez pomyłkę nieprawidłowo opisując rewizję. Na
przykład złym numerem buga. A potem weź szukaj w historii poprawki na to
co zrobiłeś.

>>> To czego "nie mam" to jest branch i tam sobie moge pieprzyć dowoli.
>> Nie możesz, bo branch jest publiczny.

> Gówno prawda. Branch to publiczna piaskownica. Mozesz tam wkladać co
> chcesz i potem to zlewać, psuć kod, generować dowolne błędy i regresje.
> jest rzecza niezrozumiałą po co miałby ktoś to śledzić poza paranoją.

Z daleka widać że nie miałeś do czynienia z kodem pisanym dla dużego
klienta. Wierzysz że managierzy takiej Nokii czy innego Sony Ericssona
mają ciekawsze rzeczy do roboty?

>>> Natomiast upublicznianie nazywa się mergowaniem z trunkiem.
>> Zupełnie mylisz pojęcia.

> Wiec co jest upublicznianiem kodu w/g Ciebie?

Zapewne wystawienie go w taki sposób, że ktokolwiek inny niż autor (np.
kolega z projektu albo przedstawiciel klienta) może ten kod obejrzeć.

> Commit na brancha? Jeśli
> masz paranoje na punkcie podglądania cudzego kodu to można zastosować
> prawa dostępu żby nikt Twoich zmian nie oglądał. Dalej nie rozumiem po co.

Żeby managier od klienta nie jojczał że "ten kod się nie nadaje,
niedopuszczalne, zrywamy umowę!".

>>> Moze po prostu inaczej rozumiemy upublicznianie. ja jako upublicznianie
>>> rozumiem wrzucenie w główne źrodła. A to że ktoś na branchu wrzucił
>>> sobie zdjęcia porno mało mnie interesuje
>> Ciekawe co by na to powiedział klient.

> Czepiasz się słów gubiąc przesłanie. Klient nie ma dostepu do branchu.

Z dokładnością do sytuacji gdy sobie zażyczy takiego dostępu. Co wcale
nie jest takie rzadkie.

> Robisz switch to revision 189 i sprawdzasz regresje. Nie ma? To robisz
> switch do 150 i sprawdzasz. Nie ma? To na 123. Listę rewizji na trunku
> svn z przyjemnością wyrzuci jesli go poprosisz.

> Informajca z ktorego brancha to pochodzi w SVN jest (od niedawna o ile
> pamiętam) ale jest *zbedna* żeby wykonać ta operację.

Czyli dostajesz coś w rodzaju "ja wiem co się zepsuło! samochód się
zepsuł!". Przejście przez historię merge'owania pozwala dokładniej
wyizolować błąd.

>>>>>> a nie w późniejszym commicie.
>>>> NIE W COMMICIE PÓŹNIEJSZYM!
>>> A jakaś to różnica po wykonaniu reverta?
>> Taka, że nie jestem badziewiarzem patrzącym się tylko na to co jest na
>> masterze/trunku/HEAD i przeszkadza mi szambo w historii projektu.

> Szambo tak naprawdę nie istnieje. Nie wpływa na cokolwiek.

Chyba że na wyszukiwanie informacji w historii.

> Jest
> przezroczyste. Jesli masz z tym problem to może to jest tylko Twoj problem.

Widać nigdy nie potrzebowałeś przeglądać historii szukając konkretnych
informacji.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2010-10-06, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2010-10-06 01:22, Michoo wrote:
>> skorzystać z wygody jaką daje C++. Teraz prezentujesz imo taki sam beton
>> tyle, że w odniesieniu do systemu kontroli wersji. Upierasz się, że
>> SVN(/C - niepotrzebne skreślić ;) ) przecież wystarcza, mimo, że małym
>> kosztem można dostać 'sporo więcej".
>
> To sporo więcej nie jest za darmo. Narzędzia wspomagające do gita,
> szczególnie klikalne, są o 100 lat za TortoiseSVN. Przynajmniej były rok
> temu kiedy usilnie szukalem *czegokolwiek* działającego, ale z chęcią
> poczytam co się zmieniło.

Eeee... że tak głupio spytam... Po co klikane?

> SVN jest bardziej intuicyjny do gita. Próg wejscia jest nisko. IDE
> zazwyczaj ma go zintegrowanego.

I zazwyczaj, zdaje się, to integracja na poziomie "zapisz zmiany",
i "wyciągnij rewizję XXX". To naprawdę tak bardzo pomaga w pracy?

>> Jedną z zalet rozproszonego systemu kontroli wersji jest to, że nie jest
>> potrzebny pełnoprawny serwer - patche można nawet i mailami przesyłać,
>> czy na jakiegoś ograniczonego ftp wrzucać.
>
> Podczas normalnej pracy z gitem ludzie narzekają na to że nie pamiętaja
> ktora poprawka z jakiego pliku jest do czego. IMHO jeśli mogę mieć
> centralny serwer to wygodniejsze że ktoś pilnuje numerków.

???
A o co chodzi z tym "nie pamiętają która poprawka z jakiego pliku jest
do czego"? Bo ja nie rozumiem. Czyżby chodziło o opisywanie komentarzami
commitów?

--
Secunia non olet.
Stanislaw Klekot

do góry

On 10/06/2010 10:56 AM, Stachu 'Dozzie' K. wrote:
> On 2010-10-06, Sebastian Biały<h...@p...onet.pl> wrote:
>> On 2010-10-06 01:22, Michoo wrote:
>>> skorzystać z wygody jaką daje C++. Teraz prezentujesz imo taki sam beton
>>> tyle, że w odniesieniu do systemu kontroli wersji. Upierasz się, że
>>> SVN(/C - niepotrzebne skreślić ;) ) przecież wystarcza, mimo, że małym
>>> kosztem można dostać 'sporo więcej".
>>
>> To sporo więcej nie jest za darmo. Narzędzia wspomagające do gita,
>> szczególnie klikalne, są o 100 lat za TortoiseSVN. Przynajmniej były rok
>> temu kiedy usilnie szukalem *czegokolwiek* działającego, ale z chęcią
>> poczytam co się zmieniło.
>
> Eeee... że tak głupio spytam... Po co klikane?

Mam wrażenie, że pisząc "klikalne" ludzie mają na myśli nie "obsługiwane
za pomocą myszki" a raczej "przedstawiające informacje w formie
graficznej". Czasem warto zobaczyć drzewo a nie s-expression, mimo, że
informacja w zasadzie ta sama.

JD

do góry

On 2010-10-06, Jędrzej Dudkiewicz <j...@n...com> wrote:
> On 10/06/2010 10:56 AM, Stachu 'Dozzie' K. wrote:
>> On 2010-10-06, Sebastian Biały<h...@p...onet.pl> wrote:
>>> On 2010-10-06 01:22, Michoo wrote:
>>>> skorzystać z wygody jaką daje C++. Teraz prezentujesz imo taki sam beton
>>>> tyle, że w odniesieniu do systemu kontroli wersji. Upierasz się, że
>>>> SVN(/C - niepotrzebne skreślić ;) ) przecież wystarcza, mimo, że małym
>>>> kosztem można dostać 'sporo więcej".
>>>
>>> To sporo więcej nie jest za darmo. Narzędzia wspomagające do gita,
>>> szczególnie klikalne, są o 100 lat za TortoiseSVN. Przynajmniej były rok
>>> temu kiedy usilnie szukalem *czegokolwiek* działającego, ale z chęcią
>>> poczytam co się zmieniło.
>>
>> Eeee... że tak głupio spytam... Po co klikane?
>
> Mam wrażenie, że pisząc "klikalne" ludzie mają na myśli nie "obsługiwane
> za pomocą myszki" a raczej "przedstawiające informacje w formie
> graficznej". Czasem warto zobaczyć drzewo a nie s-expression, mimo, że
> informacja w zasadzie ta sama.

No OK. Ale to by pisali "przedstawiające w formie graficznej".
`git show-branch' przedstawia historię branchy w formie właśnie
graficznej, a nijak go klikanym nazwać nie można.

--
Secunia non olet.
Stanislaw Klekot

do góry

Stachu 'Dozzie' K. wrote:
> On 2010-10-03, Sebastian Biały <h...@p...onet.pl> wrote:
>> On 2010-10-03 23:40, Stachu 'Dozzie' K. wrote:
>>> SVN wystarcza do momentu, gdy potrzebujesz *czegokolwiek* innego niż po
>>> prostu "zapisz to co ostatnio robiłem". Na przykład pracy z gałęziami (w
>>> SVN to wygodne jak wrzód na dupie).
>> Wygodne jeśli wspełnia twoje oczekiwania czego w *twoim* wypadku
>> widocznie nie można powiedzieć.
>
> Używałeś gałęzi w SVN?

Owszem :)

> Nie? To nie mamy o czym rozmawiać[*]. Dopiero od
> niedawna (jak na cały system kontroli wersji, bo raptem od dwóch lat)
> obsługuje w miarę automatycznie merge'owanie między gałęziami, ale to
> jest bardzo upierdliwe, bo wystarczy zrobić głupią zmianę nazwy katalogu
> w obrębie gałęzi i już dostajesz radosny komunikat "you have unmerged
> changes; try merging them first" wzięty z sufitu.
>
> [*] Niżej się przyznajesz że jednak pracujesz. A widziałeś jak gałęzie
> działają w czymkolwiek innym?

Nie wszyscy mają potrzebę przewracania całej struktury kodu do góry
nogami. BTW po takim przewróceniu trudniejszy merge jest drobiazgiem :)


>> Jednak SVN spełnia oczekiwania bardzo
>> dużej grupy ludzi co łatwo zaobserwować po ilości tworzonego w nim kodu
>> szczególnie jesli ktoś migruje z SS, CVS czy nawet CC.
>
> Bo a) ta bardzo duża grupa ludzi potrzebuje tylko "zapisz to co ostatnio
> robiłem" i b) SS i CVS są dosyć ubogimi systemami kontroli wersji.
> Natomiast CC jest po prostu drogie i skomplikowane, choć z punktu
> widzenia używania to akurat ClearCase jest fajniejsze od SVN.
>
>> PS. Na codzien pracuje z gałęziami w SVN i jeszcze nie biorę fluoksetyny
>> podobnie jak masa ludzi na około. Widocznie trzeba wiedziec jak tego używać.
>
> Tak? Ja też pracowałem z gałęziami w SVN. I jakoś niezbyt się nadawały.
> Taka proteza, porównując z prawie czymkolwiek innym na rynku (ClearCase,
> git, Mercurial).

SVN wymusza pewien określony porządek -- to w paru miejscach jest nawet
zaletą.

[...]
kładnia była tworzona
>> na trzeźwo w przeciwieństwie do Perla czy innego PHP.
>
> O? To komitet Perla nadużywa alkoholu podczas zatwierdzania propozycji
> składniowych? Pierwsze słyszę. Możesz podać źródło tych rewelacji?
>

Nie wiem czego nadużywa, ale to był bardzo "twardy stuff". ;)

pzdr
\SK

--
"Never underestimate the power of human stupidity" -- L. Lang
--
http://www.tajga.org -- (some photos from my travels)

do góry