siek: koniec pracy na dzisiaj, czas do domu

reklama

siek

19:19 03/07/2009

koniec pracy na dzisiaj, czas do domu

Promuj wpis:

Polecane wpisy ustaw kategorię

reklama

18:58 03/07/2009

nawiązując do flaker.pl/f/2052260

- zaprosiliśmy Kamila na ostatni w tym sezonie outdoorowy #Barcamp (11. lipca 13:00 @Malta)... zobaczymy czy da radę nas odwiedzić :)

ak74 @az - :) [odpowiedz]
winny yeah! :) [odpowiedz]
mart lans!
nrm niefajne!

reklama

Goorsky

17:45 03/07/2009

W drodze.

D3X co to za futrzak? :) [odpowiedz]
az @D3X - imho to kuzyn @niuchacz'a [odpowiedz]
D3X @az - a jest na #flaker.ze? :) [odpowiedz]
Goorsky @az - prosił żeby go pozdrowic :) [odpowiedz]
Goorsky dodałem tego flaka do historyjki:Być harcerzykiem

reklama

kacperix

18:53 03/07/2009

Zabieram się do użycia systemu kontroli wersji w #hostrank i zastanawiam się pomiędzy #SVN a #GIT. W pierwszym przypadku mam #TortoiseSVN co bardzo ułatwia używanie SVNa, ale przy duuużej ilości plików wszelkie operacje się wydłużają, natomiast w GIT'cie nie doszukałem się narzędzi desktopowych, ale za to jest o wiele szybszy (tak czytałem na kilku stronach). #Drogiflaku Może od Was usłyszę coś co pozwoli mi się zdecydować konkretnie? :)

iktorn Git bo github [odpowiedz]
syllepsa Git bo jest git [odpowiedz]
D3X @sharnik +1 [odpowiedz]
syllepsa a przepraszam wycofuję się, gdyż ja jeszcze gita nie używałem. [odpowiedz]
D3X @syllepsa - rotfl! [odpowiedz]
nrm svn ;) git nam tylko w ch* czasu zabrał i mase problemów narobił ;) svn daleko do idealności ale... działa bez problemu ;) [odpowiedz]
kacperix @iktorn - akurat z githuba nie zamierzałem korzystać ;) @nrm - problemy od strony technicznej czy użytkownika (słaba znajomość Gita)? jakiś przykład mógłbyś podać? :) @ravbaker - używałeś może tego TortoiseGit? u Was w pracy na czym się opieracie? [odpowiedz]
nrm za duzo by pisac. ogolnie migracja 3os teamu z svn na gita przyniosla same problemu i strate czasu. wytrzymalismy 3 tygodnie wiec nie wiem czy w koncowej fazie mozna to zwalic na slaba znajomosc. [odpowiedz]
nrm głównie z konfliktami. bez przerwy na kazdym kroku. tracilismy ogrom czasu na googlanie jakis dziwacznych komunikatow ;) a to ma dzialac. od reki. 5 komend na krzyz wystarczy aby to obslugiwac. a tu tyle problemow bylo ;) wrocilismy do SVN bo nie bylo czasu na eksperymenty i jak reka odial. zapomnielismy o systemie i zajelismy sie praca ;) [odpowiedz]
kacperix @ravbaker - właśnie zdążyłem zauważyć, że git inaczej rozporządza repozytoriami i nie jest z założenia systemem scentralizowanym (jak SVN) co trochę mnie dezorientuje, no ale trochę praktyki i powinno być lepiej ;) [odpowiedz]
kacperix dobra, zdecydowane - Git (bez żadnych gui, prosto z konsoli) ;] a jak się nie sprawdzi to wtedy SVN ;) [odpowiedz]
eastman dodałem tego flaka do historyjki:Ciężkie życie Kodera i Project Managera
Thotep Jest przecież jeszcze #Mercurial, który jest szybki, prosty w obsłudze, działa dobrze na każdym OSie i ma fajne gui (TortoiseHg). [odpowiedz]
kacperix @Thotep - właśnie wczoraj kończąc studiowanie artykułów natknąłem się też na niego i przyciągnął moją uwagę, dlatego też jeszcze się na chwilę wstrzymać z Git ;)
Ale nadal nie do końca pojmuję logikę tych systemów zdecentralizowanych. w SVN leżało wszystko na serwerze, z tego się brało, tam się wysyłało (commity itp), a w tych są jakieś lokalne, one mogą być dzielone z innymi userami, a jak będzie 10 osób i chce żeby każdy miał zmiany które wprowadziłem to będę musiał każdemu z osobna wysyłać zmiany...? ehh, stanowoczo za mało chyba wiem, żeby to pojąć lepiej ;/ [odpowiedz]
D3X @kacperix - nie, trzymasz w jednym miejscu (np. github) gałąź 'master' czy coś w ten deseń. każdy lokalnie prowadzi development w swoim branchu (albo w kilku jak robi kilka ficzerów niezależnych). commituje do tego lokalnego brancha, potem jak ficzer jest skończony to merguje z masterem. potem jak ktoś ma zamiar rozwijać nowy ficzer to pobiera mastera, odgałęzia od niego znowu swój branch, edytuje i merguje z masterem. może wydaje się trochę zakręcone, ale naprawdę świetnie się sprawdza w praktyce :) no i nie trzeba codziennie robić svn up (znaczy git pull), żeby być na bieżąco. po prostu w pewnym momencie się oddzielasz od głównej gałęzi i jak skończysz swoje to się z nią łączysz :) [odpowiedz]
kacperix @D3X - aha, no teraz już mniej więcej mam wyobrażenie co i jak ;d thx for explain ;) [odpowiedz]
bartosz @D3X spoko. naucz się tylko jeszcze różnicy między branchem a repozytorium i będzie całkiem ok ;) @kacperix - nwiki.pl/git - najlepszy znany mi "opis" gita autorstwa @szajbus.a [odpowiedz]
D3X @bartosz - możliwe, że trochę skrótowo napisałem, ale wbrew pozorom odróżniam branch od repo :) [odpowiedz]
bartosz no to została ci już tylko różnica między mergem a pushem! :) [odpowiedz]
bartosz (nie to, żebym się czepiał, ale taki poradnik dla nowicjuszy to niezbyt najlepsza rzecz) [odpowiedz]
Mekk O, wojna svn-git-hg i tu! Ja za mercurialem. Aha, autoreklama: mekk.waw.pl/mk/narzedzia/vc [odpowiedz]
kacperix @Mekk - dlaczego mericurial? [odpowiedz]
D3X @bartosz - to nie miał być poradnik tylko zgrubny opis pracy z gitem. do konkretnym poleceń i tak jest manpage :) [odpowiedz]
bartosz tak się akurat składa, że dokumentacja to jedna z największych wad gita ;) jest strasznie zamieszana i popieprzona. [odpowiedz]
Mekk @kacperix odp nie wprost notatnik.mekk.waw.pl/archives/138-uklad.html [odpowiedz]
Mekk Aha w firmowym kontekście dorzuciłbym bazaar - próbują konkretne procesy proponować. Nie używałem ale lubię ich doce [odpowiedz]
Thotep @kacperix - tutaj bardzo fajne omówienie ogólnej idei rozproszonych systemów kontroli wersji, polecam: betterexplained.com/...to-distributed-version-co... (choć art u @Mekk.a też jest dobry - ale nie ma obrazków ;) ) [odpowiedz]
kacperix @Thotep - dzięki, b. fajny art. od @mekk również :) po obyciu się trochę w tych wszystkich tekstach, opiniach, forach, porównaniach wezmę na start #Mercurial'a ;) So, let the party begin ;d [odpowiedz]
Thotep A proszę bardzo. :) [odpowiedz]
kacperix dodałem tego flaka do historyjki:dev HostRank
onjin zmigrowaliśmy główny projekt z svn na git, co zmniejszyło repo z prawie 1GB do ok. 60MB, przyśpieszyło prace gdyż większość branchy bugs/features robi developer lokalnie bez czekania na connect, log/diff jest lokalny, konfliktów jest mniej dzięki rebase przy pull. Wystarczyło kilka prób/eksperymentów + objaśnienie reszcie drużyny. Pozostałe kilkadziesiąt pomniejszych projektów są w svn i wyciągamy je przy pomocy 'git svn clone', lub jak ktoś chce to nadal svn. ogólnie duży + [odpowiedz]
alex-pl fajne!
onjin dodatkowo dzięki gitosis-admin + gitweb mamy taki mały firmowy github; dostęp poprzez klucze ssh, dowolny layout repozytoriów np username/repo.git, otherrepo.git, tools/deployment/sometool.git i uprawnienia read i/lub write do odpowiedniego repa przez odpowiedniego usera [odpowiedz]
kacperix @onjin - no to nieźle się zmniejszyła pojemność :) dla eventio.pl używamy git'a z gitosos i muszę przyznać, że jest całkiem dobrym narzędziem pomimo faktu, że na początku było trochę problemów ze zrozumieniem i rozwiązaniem kilku problemów :) [odpowiedz]
onjin @kacperix - dokładnie, trzeba dobrze zrozumieć różnicę pomiędzy svn, a git. przynajmniej jedna osoba, która potrafi to przekazać :) [odpowiedz]
seban @rupert można też zabrać się za tłumaczenie progit [odpowiedz]
bartosz @rupert - nie do końca chyba kumasz dlaczego się tłumaczy książki ;) [odpowiedz]
bartosz @rupert - nie wiem jak ty to widzisz, ale wg mnie nie ma najlepszego sposobu na poznanie czegoś niż nauczenie kogoś (if you know what i mean) [odpowiedz]
bartosz tego czegoś. a przy tłumaczeniu trzeba wszystko czaić w 100% [odpowiedz]