On 2010-10-04, Sebastian Biały <h...@p...onet.pl> wrote:
> On 2010-10-04 01:56, Stachu 'Dozzie' K. wrote:
>> Używałeś gałęzi w SVN? Nie?
>
> Używam na codzień.
>
>> 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.
>
> Wyjmujesz jeden aspekt pracy z jakiegoś systemu kontroli wersji i
> wymachujesz nim pokazując: patrzcie, tu jest do dupy więc cała reszta
> jest do dupy !

Nie. Ty wyjąłeś jakiś pierwszy z brzegu system kontroli wersji,
zakładając niewprost że jest sensowny. Ja wskazuję że jest głupi (VCS,
znaczy się), nic więcej i nic mniej.

> Jakoś problemy z praca SVN nie powodują masowych migracji na coś innego,
> szczegolnie jak to jest maly projekcik.

Jak to jest mały projekcik to wystarcza samo "zapisz moje zmiany w takim
stanie w jakim są".

>> Dowiedź że jest gorszy.
[mowa o Perlu]
><Ziew>. Niby jak? Jakie są warunki gorszości ktore Cie przekonają?
> Nieczytelność kodu źrodłowego jest wystarczająca?

Czyjego? Kretynów nieumiejących pisać programów? Żadna wada, to samo
jest w dowolnym innym języku.

>> O? To komitet Perla nadużywa alkoholu podczas zatwierdzania propozycji
>> składniowych? Pierwsze słyszę. Możesz podać źródło tych rewelacji?
>
> Obserwacje własne wyniku ich pracy

ORLY? Których części wyniku ich pracy?

> i opinie ludzi pracujacych zawodowo w
> Perlu - wnioski nasuwają się niejako automatycznie.

Dziwne. Znam ludzi mających cokolwiek krytyczne nastawienie do używanego
języka, ale nigdy nie słyszałem od nich zarzutu nadużywania alkoholu
przez komitet.

> I są identyczne jak
> w PHP, tylko żed w PHP przy okazji byli jeszce dodatkowo po ciężkiej
> imprezie w akademiku.

Od PHP proszę się tu odpierwiastkować. W tej części mówimy o Perlu.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2010-10-04, Andrzej W. <awa_wp.a_to_wytnij> wrote:
> W dniu 2010-10-04 01:43, Stachu 'Dozzie' K. pisze:
>> On 2010-10-03, Andrzej W.<awa_wp.a_to_wytnij> wrote:
>>>
>>> Git wymaga shella do instalacji...
>>
>> Ę? Właśnie zniknąłeś w mojej firmie gita via WebDAV.
>>
>
> Działać a instalować to dwie różne rzeczy.

Ach. Mój moduł korekcji błędów zadziałał.

Zasadniczo to nie, git nie wymaga shella do założenia repozytorium.
Wystarczy możliwość uploadowania plików i skonfigurowany WebDAV.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2010-10-04 09:37, Stachu 'Dozzie' K. wrote:
> Nie. Ty wyjąłeś jakiś pierwszy z brzegu system kontroli wersji,

Nie pierwszy z brzegu tylko pierwszy z góry. Pod kątem popularności,
wsparcia, wygody, integracji z IDE itp bzdurki. No tak, ale czegoś tam
nie merguje w 0.01% napotkanych przypadków za pierwszym razem. Fatal ...

> Ja wskazuję że jest głupi (VCS,
> znaczy się), nic więcej i nic mniej.

To dziwne, bo SVN w ogólności jast całkiem wygodny. Zaryzykuje że o rząd
wielkości od gita którego chyba promujesz. Tylko że git to jest inna
filozofia która jest zbędna kiedy ma się centralny serwer.

> Jak to jest mały projekcik to wystarcza samo "zapisz moje zmiany w takim
> stanie w jakim są".

Najzabawniejsze jest to ze SVN w dużych projektach (ale skoncentrowanych
developerach) sprawdza sie na tyle że developerzy nie snią po nocach o
migracji do innych wynalazków. Może po prostu jest wystarczający. Z
resztą sam pracowałem na paru projektach w SVN i zapewniam, że nie byly
to aplikacje hello world. I wiesz, daje radę. Tak po prostu. Branche
dzialają, mergowanie działa. Nie przypuszczam żeby inicjator wątku
chciał coś specjalnie więcej.

Git jest fajny, tylko kompletnie zbędny dla pytacza.

> ale nigdy nie słyszałem od nich zarzutu nadużywania alkoholu
> przez komitet.

Dobra, eot.

do góry

On 2010-10-04, Sebastian Biały <h...@p...onet.pl> wrote:
>> Ja wskazuję że jest głupi (VCS,
>> znaczy się), nic więcej i nic mniej.
>
> To dziwne, bo SVN w ogólności jast całkiem wygodny. Zaryzykuje że o rząd
> wielkości od gita którego chyba promujesz. Tylko że git to jest inna
> filozofia która jest zbędna kiedy ma się centralny serwer.

System kontroli wersji w ogólności też jest zbędny. Tylko disconnected
operations jakoś się dość często przydają, podobnie jak łatwość obsługi
wielu branchy, wystawianie repozytorium po gołym HTTP, naprawialność
repozytorium młotkiem i parę innych rzeczy, których brakuje
w Subversion.

>> Jak to jest mały projekcik to wystarcza samo "zapisz moje zmiany w takim
>> stanie w jakim są".
>
> Najzabawniejsze jest to ze SVN w dużych projektach (ale skoncentrowanych
> developerach) sprawdza sie na tyle że developerzy nie snią po nocach o
> migracji do innych wynalazków. Może po prostu jest wystarczający.

I dlatego linuksowy kernel jest na gicie. Dlatego X.Org jest na gicie,
mimo że był na SVN, zdaje się. Dlatego Mozilla i OpenOffice.org używają
Mercuriala. Bo SVN jest, hmm... wystarczający?

> Z
> resztą sam pracowałem na paru projektach w SVN i zapewniam, że nie byly
> to aplikacje hello world. I wiesz, daje radę. Tak po prostu. Branche
> dzialają, mergowanie działa.

Kulawo bo kulawo, ale działa. Tylko że właśnie kulawo.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2010-10-04 19:13, Stachu 'Dozzie' K. wrote:
> System kontroli wersji w ogólności też jest zbędny. Tylko disconnected
> operations jakoś się dość często przydają, podobnie jak łatwość obsługi
> wielu branchy, wystawianie repozytorium po gołym HTTP, naprawialność
> repozytorium młotkiem i parę innych rzeczy, których brakuje
> w Subversion.

Gdyby autor wątku nie szukał centralnego serwera to miałbys wiele racji.
Gdyby trzeba było robić branche w środku lasu też. Gdyby repozytorium
trzymał na dyskietkach też. W ogóle *miałbyś* rację gdyby nie inne potrzeby.

>> Najzabawniejsze jest to ze SVN w dużych projektach (ale skoncentrowanych
>> developerach) sprawdza sie na tyle że developerzy nie snią po nocach o
>> migracji do innych wynalazków. Może po prostu jest wystarczający.

> I dlatego linuksowy kernel jest na gicie. Dlatego X.Org jest na gicie

*skoncentrowanych* developerach. Czytaj proszę dokładnie. Po co komu
rozproszony system kontroli wersji przy dwóch osobach, centralnym
serwerze i dostepie do netu 24/h?

> mimo że był na SVN, zdaje się. Dlatego Mozilla i OpenOffice.org używają
> Mercuriala. Bo SVN jest, hmm... wystarczający?

Do *skoncentrowanych* małych projektów jest bardzo wygodny.

> Kulawo bo kulawo, ale działa. Tylko że właśnie kulawo.

Rozumiem, wiesz lepiej jak mi działalo. Ok, rozumiem.

Teraz już EOT definitywnie, ale rozumiem że będziesz mial jakieśtam
ostatnie słowo o wyższości gita nad resztą świata pod kazdym względem,
więc z chęcią wysłucham ziewając.

do góry

W dniu 2010-10-04 07:16, s...@g...pl pisze:
> On Sun, 03 Oct 2010 13:37:11 +0200
> "Andrzej W."<a...@w...pl> wrote:
>
> quick google:
> http://sourceforge.net/projects/asvcs/
> http://www.top-cat.com/intraversion.php
>
> ... w sumie to nic o nich nie wiem :)

Znalazłem je, ale oba projekty nie żyją już 2-3 lata.


--
Pozdrawiam,
Andrzej

do góry

On 2010-10-04, Sebastian Biały <h...@p...onet.pl> wrote:
[...]
>
> Gdyby autor wątku nie szukał centralnego serwera to miałbys wiele racji.
> Gdyby trzeba było robić branche w środku lasu też. Gdyby repozytorium
> trzymał na dyskietkach też. W ogóle *miałbyś* rację gdyby nie inne potrzeby.
>
[...]
>
> *skoncentrowanych* developerach. Czytaj proszę dokładnie. Po co komu
> rozproszony system kontroli wersji przy dwóch osobach, centralnym
> serwerze i dostepie do netu 24/h?

Ja bym wybrał Gita nawet przy 2 developerach. I decyzję o tym opieram na
doświadczeniu w sytuacji, w której Ty przekonujesz, że SVN sprawdziłby
się lepiej - ostatnie 3 lata pracy w firmie ok. 10 developerów,
z serwerem SVN w sieci lokalnej:
- 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),
- 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,
- Git działa w trybie offline! Wydawałoby się, że jeśli w ciągu roku
spędza się 2 dni poza biurem, to nie ma potrzeby używania
rozproszonego VCS. Ale ja się w czasie tych dwóch dni w roku znalazłem
w sytuacji, w której bez kopii projektu w repozytorium Gita bym sobie
nie poradził,
- w dalszym ciągu uczę się zarządzania gałęziami tak, żeby potem nie
pogubić się w gąszczu ;-), ale nie chciałbym nie mieć sprawnej obsługi
gałęzi,
- Git ma polecenie bisect, które znakomicie ułatwia znajdowanie
commitów, które wprowadziły regresję.

Jedyne, co moim zdaniem przemawia na korzyść SVN, to jego popularność.
Być może dla drobnego projektu nie opłaca się uczyć obsługi nowego
narzędzia, ale na dłuższą metę zdecydowanie polecam.

Jeszcze zaznaczę, że na stanowisku, na którym piszę kod, używam Linuksa.
Nie wiem, jak wygląda obsługa Gita pod Windows, choć wydaje mi się, że
z powodzeniem używałem go kiedyś pod Cygwinem.

--
Pozdrawiam,
Lech Lorens - lp.pw@snerol_hcel

do góry

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)

b) moze zainteresuj się funkcja "switch" zamiast w kółko checkoutowac

c) Jak masz kilka GB projektu to jesteś w dupie tak czy inaczej

> - 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,

- Marek, masz tam tą poprawkę na buga 18876 ?
-No, mam, weź sobie te pliki, to pierwsze 25 linijek od 548 i jeszcze
w 13445 zmień sobie warunek na większy. A, i jeszcze w pliku x.cpp jest
do zmiany #define, w 15 lini
- Ok, dzięki.

A zakładając że to powyzsze nie ma sensu to jaki sens ma commitowanie
pół pliku na brancha na tyle często żeby miało to istotne znaczenie? Ja
zazwyczaj wykonuje tą poprawkę *przed* commitem aby miec pewnośc że się
kompiluje, wiec tutaj mechanizm średnio się przydaje.

> - Git działa w trybie offline! Wydawałoby się, że jeśli w ciągu roku
> spędza się 2 dni poza biurem, to nie ma potrzeby używania
> rozproszonego VCS. Ale ja się w czasie tych dwóch dni w roku znalazłem
> w sytuacji, w której bez kopii projektu w repozytorium Gita bym sobie
> nie poradził,

To jest jakis argument. Pytanie czy krytyczny na autora. Bo dla mnie ma
wartośc bliską 0.

> - w dalszym ciągu uczę się zarządzania gałęziami tak, żeby potem nie
> pogubić się w gąszczu ;-), ale nie chciałbym nie mieć sprawnej obsługi
> gałęzi,

Co jest *niesprawnego* poza duperelami w obsłudze gałęzi SVN? Bo używam
i nie placzę ani włosow nie wyrywam. Może po prostu wiem jak używać.

> - Git ma polecenie bisect, które znakomicie ułatwia znajdowanie
> commitów, które wprowadziły regresję.

Obawiam się że zrobienie bisect za pomoca paru linijek bashu + svn nie
stanowi żadnego kłopotu. git nie wprowadza tutaj funkcjonalnie
kompletnie nic.

Zaznaczam że nie uwazam SVN za najlepszy system wersjonowania. Nie
potrafie jednak przejśc bez slowa wobec malo sensownych argumentów typu:

- potrzebuje centralnego serwera na mały projekt dla dwoch osób
- to weź gita, możesz mieć zdecentralizowany, dla tysiąca osób, z
gównianymi narzedziami gui i bisect oraz uzywają tego w kernelu !!!11
- aha, ale ...

Teraz już EOT definitywnie-definitywnie. Pozdrawiam gitowców.

do góry

On 2010-10-04, Sebastian Biały <h...@p...onet.pl> 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 nie znaczy że nie byłoby widać szybkości gita.

> c) Jak masz kilka GB projektu to jesteś w dupie tak czy inaczej

Chyba że używasz czegoś, co efektywnie sobie z taką ilością danych
radzi. Na przykład gita.

> A zakładając że to powyzsze nie ma sensu to jaki sens ma commitowanie
> pół pliku na brancha na tyle często żeby miało to istotne znaczenie?

Bo pierwsze pół dotyczy innej poprawki niż drugie?

>> - w dalszym ciągu uczę się zarządzania gałęziami tak, żeby potem nie
>> pogubić się w gąszczu ;-), ale nie chciałbym nie mieć sprawnej obsługi
>> gałęzi,
>
> Co jest *niesprawnego* poza duperelami w obsłudze gałęzi SVN? Bo używam
> i nie placzę ani włosow nie wyrywam. Może po prostu wiem jak używać.

Albo nie robisz nic bardziej zaawansowanego, co by mogło zepsuć obsługę
gałęzi. Tak też się zdarza. Mnie się merge'owanie psuło po dowolnych
przenosinach pliku czy katalogu. To jest uciążliwe.

>> - Git ma polecenie bisect, które znakomicie ułatwia znajdowanie
>> commitów, które wprowadziły regresję.
>
> Obawiam się że zrobienie bisect za pomoca paru linijek bashu + svn nie
> stanowi żadnego kłopotu. git nie wprowadza tutaj funkcjonalnie
> kompletnie nic.

Obawiam się że najpierw te linijki trzeba napisać. Podobnie jak na
przykład narzędzie eksportujące katalog repozytorium do tarballa.
Ot, takie podejście pascalowe: "to nie problem sobie napisać samemu".
I nieważne że gdzieś indziej ktoś to już ma w standardzie.

> Zaznaczam że nie uwazam SVN za najlepszy system wersjonowania. Nie
> potrafie jednak przejśc bez slowa wobec malo sensownych argumentów typu:
>
> - potrzebuje centralnego serwera na mały projekt dla dwoch osób
> - to weź gita, możesz mieć zdecentralizowany, dla tysiąca osób, z
> gównianymi narzedziami gui i bisect oraz uzywają tego w kernelu !!!11

Sam się kopnąłeś w dupę mówiąc że programiści w dużych projektach nie
śnią po nocach o przesiadce z Subversion. Otóż owszem, śnią.
I nie wyciągałem argumentu o tysiącach osób. Narzędzi GUI też nie
dotykałem, choćby dlatego, że nie mogę zrozumieć czym się różni
wyklikanie numeru rewizji do checkoutu od wpisania tego w wierszu
poleceń, poza takim szczegółem że drugie jest wygodniejsze, bo można
choćby skrypt do bisekcji napisać.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 4 Paź, 23:31, Sebastian Biały <h...@p...onet.pl> 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)
Jakbyś zamiast podniecania się SVN-em poużywał trochę gita, to byś
wiedział, że operacje typu log, commit, zmiana brancha są w nim
_natychmiastowe_. SVN z jego oczekiwaniem w nieskończoność na
zakończenie byle pierdółki (nawet po LAN-ie) jest po prostu śmieszny.

> b) moze zainteresuj się funkcja "switch" zamiast w kółko checkoutowac
Przecież w SVN-ie to leci po sieci. Czyli tak czy siak się czeka.

> > - 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,
>
> - Marek, masz tam tą poprawkę na buga 18876 ?
>   -No, mam, weź sobie te pliki, to pierwsze 25 linijek od 548 i jeszcze
> w 13445 zmień sobie warunek na większy. A, i jeszcze w pliku x.cpp jest
> do zmiany #define, w 15 lini
> - Ok, dzięki.
O, dowcip. Mało śmieszny co prawda.

> A zakładając że to powyzsze nie ma sensu to jaki sens ma commitowanie
> pół pliku na brancha na tyle często żeby miało to istotne znaczenie?
Taki ma sens, że nie raz, nie dwa, a nawet nie sto razy się zdarzało,
że w jednym pliku nagle znalazły się zmiany dotyczące kilku różnych
rzeczy na raz. I trzeba to było jakoś zacommitować. Na SVN-ie albo
zrobisz burdel commitując wszystko na raz (bardzo częsty i przykry
widok), albo się będziesz dłubał przez pół dnia próbując zrobić
dobrze. A jak się pomylisz, to kaplica, bo poszło na serwer i się już
odkręcić tego nie da w żaden sposób.

> > - Git działa w trybie offline! Wydawałoby się, że jeśli w ciągu roku
> >    spędza się 2 dni poza biurem, to nie ma potrzeby używania
> >    rozproszonego VCS. Ale ja się w czasie tych dwóch dni w roku znalazłem
> >    w sytuacji, w której bez kopii projektu w repozytorium Gita bym sobie
> >    nie poradził,
>
> To jest jakis argument. Pytanie czy krytyczny na autora. Bo dla mnie ma
> wartośc bliską 0.
Patrz wyżej. Nie wyobrażam sobie (już), żeby zmiany szły na serwer od
razu podczas commita. Zdarza mi się czasem popełniać dosyć oczywiste
błędy i bardzo sobie cenię możliwość skorygowania lokalnej historii
repozytorium, tak żeby o moich pomyłkach nikt się nigdy nie
dowiedział. Co więcej, początkowe implementacje nowych rzeczy mają do
siebie to, że są robione trochę na czuja. Często po jakimś czasie
(godzina, pół dnia, dwa dni), w miarę zgłębiania problemu wiedza na
jego temat poszerza się o tyle, że tą początkową implementację chciało
by się zmienić. Git daje mi taką możliwość, SVN nie.

> > - w dalszym ciągu uczę się zarządzania gałęziami tak, żeby potem nie
> >    pogubić się w gąszczu ;-), ale nie chciałbym nie mieć sprawnej obsługi
> >    gałęzi,
>
> Co jest *niesprawnego* poza duperelami w obsłudze gałęzi SVN?
Wszystko. Sam pomysł na realizację jest poroniony.

> Bo używam
> i nie placzę ani włosow nie wyrywam.
Ludzie wymieniający się kodem na dyskietkach pewnie też nie narzekają.

> Może po prostu wiem jak używać.
To ile w repozytoriach które używasz robiłeś _prywatnych_ gałęzi kodu
z _eksperymentalnymi_ rzeczami które nie wiesz czy zadziałają i w
zasadzie wstyd jest je komuś pokazywać? W SVN-ie taka gałąź będzie
widoczna do końca świata. W gicie dopiero wtedy, gdy ją opublikuję w
ten czy inny sposób.

> > - Git ma polecenie bisect, które znakomicie ułatwia znajdowanie
> >    commitów, które wprowadziły regresję.
>
> Obawiam się że zrobienie bisect za pomoca paru linijek bashu + svn nie
> stanowi żadnego kłopotu.
Chciałbym zobaczyć w jaki sposób te kilka linijek w bashu radzi sobie
z SVN-owymi merge'ami pozbawionymi historii.

> git nie wprowadza tutaj funkcjonalnie
> kompletnie nic.
Poza szybkością, gotowością rozwiązania, automatyzacją i możliwością
poprawienia błędu u źródła, a nie w późniejszym commicie. Ale poza tym
to zupełnie nic.

do góry