Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
VIII. Basque Tournament of Atari 2600 Kolejna relacja, wśród otrzymywanych od naszego przyjaciela Egoitza z Kraju Basków.
atari.area forum » Bałagan » Systemy kontroli wersji
Zaloguj się lub zarejestruj by napisać odpowiedź
aaaleee.... mercurial :( ;)
no, bo mamy 2011 rok :)
Jestem staroświecki, ale nie kumam VCSów, w których rewizja nie jest kolejnym numerem. Niby ten numer nic nie znaczy, ale jednak...
nie ma co kumać, CVS i SVN ssie. Szczególnie przy projektach z gazylionem branchy, które potem są merdżowane z powrotem do trunka (konflikty drzewne po prostu uwielbiam i naprawianie ich zajmuje więcej czasu niż powinno). No i serwer jest jeden i musi być zawsze sprawny.
Jak zacząłem używać mercuriala to jakoś nie chce mi się do svn'a wracać (chociaż mam jeszcze kilka projektów właśnie na tym SCMie).
no, bo mamy 2011 rok :)
I zamiast coś po staroświecku po prostu działać jak SVN czy CVS to może się nowocześnie pieprzyć jak Hg :)
Mnie chodzilo tylko o to że VCS napisany w pytongu, zasadniczo ssie ;) GIT rulez :D
laoo: w GITcie (i pewnie Mercurialu), numer rewizji jest równocześnie skrótem SHA1 dzięki któremu możesz sobie zweryfikować czy ci ktoś nie podłożył zgniłego jaja. Niby nic, a jednak może się przydać.
Co kto woli, jedyna wada gita to taka, że pod windą jest z nim problem (instalacja ssie (potrzebny specjalny msys z gitem), użytkowanie też). Python jest ok do części zastosowań przy mercurialu się sprawdza.
Jakbym robił soft tylko pod linuksem to ok git może sobie być, ale tak nie jest, bo przełączam się często między różnymi OS'ami/kompami, więc został mercurial. Jest python, instaluje się i po prostu działa.
saulot: pod windą git nie ma najlmniejszych problemów. Z TortoisGitem śmiga świetnie. Się instaluje i po prostu działa :)
Tortoisegit polega na msysie o którym wspominałem wyżej, cytat ze strony domowej tortoisegit:
"Install: Please install msysgit 1.6.1 or above before install tortoisegit http://code.google.com/p/msysgit"
I nie pisałem, że git źle działa pod windą.. Każdy używa co mu podpasuje.
No więc w czym problem? Wystarczy umieć czytać.
Btw. zła opinia o GITcie pod windą prawdopodobnie wzięła się z pierwszych kompilacji robionych pod cygwinem, który był wolne (z winy cygwina). Msysowe nie mają tego problemu.
w tym, że nie chce mi się doinstalowywać specjalnego środowiska do udawania unixa/linuksa (specjalnie przygotowany msys z gitem), żeby używać tylko jedno narzędzie. Mercurial tego nie potrzebuje i to jest dla mnie wystarczające.
A TortoiseGit nie jest żadnym argumentem, bo to jest tylko shell. TortoiseHg też jest, no i co z tego?
No ale nikt nie każe instalować całego środowiska. Instalujesz msysgita który waży kilka mb i to wszystko. A Mercurial potrzebuje Pythona, przez co jest wolniejszy, żre więcej pamięci i dziedziczy 'ssanie' ;)
W epoce gigabajtów pamięci ram i gigahercowych procków 'wolniejszy' do mnie zupełnie nie przemawia, mam kompa niech robi, ma działać.
A problemem msysgita jest samo 'msys' . Jak będzie samo 'git' bez pośredników to będzie git i się czepiał nie będę ;).
msys jest potrzebne bo git jest napisany pod systemy unixowe, które wymagają na windzie paru dodatków. Ciężko to obejść bez przepisywania połowy projektu od nowa. To po prostu biblioteka implementująca pewne API i tyle.
Punkt widzenia na to co ssie, a co nie, zależy także od punktu siedzenia. Pół tego wątku padło ofiarą faktu, że git nie jest przenośny: Torvalds napisał go dla siebie, żeby łatwiej zarządzać developowaniem kernela i miał w nosie inne zastosowania, w tym to, że ktoś chciałby uruchamiać go sobie pod windą. Wątpię, żeby taka pythonowa proteza mu się podobała, skoro głównym featurem gita jest prędkość działania (albo zużywanie mało prądu, jeśli chcemy być trendy). Do silnie rozproszonego developingu projektów opensourcowych, gdzie każdy lubi mieć swojego brancha, jak najbardziej, ale do innych zastosowań mam wątpliwości.
Przypominam, że wątek nie jest o tym jaki VCS jest najlepszy. Jeśli się coś nie podoba to spadać na drzewo. NIe będe się tłumaczył z tego dlaczego mi jest wygodnie używać Mercuriala i mam gdzieś dlaczego git jest lepszy. Fajnie by było jakby admin przeczyścił ten spam.
Niepozdrawiam.
MM: Done, pozdrawiam :)
MM: Dzięki!:)
Sqward: to tylko taki przyjacielski flejm ;)
Laoo: bycie rozproszonym ma też kilka innych zalet.
- commitujesz kiedy chcesz i nie musisz trzymać się tu sztywnych reguł (np, odpalenia wszystkich unit testów przed commitem)
- nie musisz być podłączony do serwera by pracować
- ty i każdy inny developer macie na dysku pełną kopię całego repozytorium (ze wszystkimi zmianami).
Owszem, GIT jest pomyślany przede wszystkim żeby być szybki i skalowalny. Do tego repozytoria w nim tworzone są relatywnie nieduże. Skoro więc narzędzia nadrzędne (np. Tortoisy) oferują wszędzie bardzo zbliżone funkcje, czemu nie używać najszybszego rozwiązania?
Tu jest bardzo ładna prezentacja nt. Gita, gdzie gada o nim Linus: http://www.youtube.com/watch?v=4XpnKHJAok8 naprawdę polecam obejrzeć.
Oglądałem to wideo już dawno temu. Lunus wyszedł w nim na egocentrycznego buraka. Tylko git, a jak nie to jesteś głupi. No poprostu żenada. Używam gita w pracy, ale na windowsa są lepsze narzędzie do mercuriala. To, że jest w pythonie mało mnie interesuje działa. Używam też Scons-a do buildowania. Zaraz ktoś powie, że make jest lepszy :P
Taki rodzaj poczucia humoru. Zresztą, wydaje mnie się, że Linus mocno zapracował na prawo bycia egocentrykiem. Wszystko ma swoje zady i walety i tyle :)
Jak wiadomo, najlepsza jest konkurencja. Czasem jednak tak jest że pokazuje się jakaś nowa technologia i sporo ludzi chwyta się za głowę "Jak myśmy dotychczas pracowali? Przecież to nowe jest o tyle i tyle lepsze", zaś kombatanci olewają to ciepłym moczem bo są mastachami od dawna używanych rozwiązań i nie chcą poznawać nowych. Tak jest właśnie z VCSami - kiedys wszyscy używali CVSa względnie SVNa, ale od momentu rozpowszechnienia się VCSów rozproszonych jakoś nie wydaję mi się aby nadal był wielki sens używać scentralizowanych. Zauważcie też pewien skok - rozproszone VCSy dały nam dodatkowe (bardzo użyteczne) narzędzia które były jak najbardziej możliwe do realizacji w scentralizowanych, tylko jakoś nikt o nich nie pomyślał (pisze tu o bisect'ach i blame'ach).
Konkludując: to że bawimy się maszynami sprzed 20 lat, nie oznacza że musimy używać tak samo przestarzałych narzędzi :)
A ja wybieram Perforce.
Ja też, ale moja firma nie :(
nie czaje waszego narzekania.
salout: w czym ci przeszkadza msys? co cie w nim tak boli? czy wiesz na czym polega to "udawanie uniksa/linuksa"? zle ci ze zamiast msys wlozyc do binarki z gitem mozesz wykorzystac biblioteki do czegos innego (bo po to jest to zmodularyzowane)?
Adam: w czym ci tak przeszkadza python? co cie w nim tak boli? w ogole wiesz jaka czesc mercuriala jest w pythonie napisana? wiesz w ogole dlaczego sie pisze w pythonie?
w obu przypadkach wyczuwam irracjonalne, wrecz religijne podejscie...
Mnie chodzilo tylko o to że VCS napisany w pytongu, zasadniczo ssie ;) GIT rulez :D
To akurat jedna wielka zaleta. I dla autorów i dla użytkowników.
Cóż, mam lekką awersję do języków które wywodzą się z basica, w których dodatkowo whitespace ma znaczenie. Co nie zmienia faktu że już od jakiegoś czasu planuje przysiąść i napisać coś w Pythonie, ot tak dla sportu (i dopisać od cv ;)). Co nie zmienia faktu że ssie ;)
Tak sobie flejmuje, ale głównie bierze się to stąd że ostatnio sporo się narobiło różnych VMów, widać to szczególnie pod Linuxem. Jest jvm, .net (mono), python, parrot, różne enginy javascriptu itp. że wspomnę o tych najpopularniejszych (w podstawowej instalce aktualnego Ubuntu na starcie odpalany jest conajmniej javascriptowy vm no i python). Wszystko ma swój narzut i zabiera pamięć i procka. Marzy mi się aby to wszystko chodziło pod jednym vmem - szybko łatwo i przyjemnie. Myślę że najlepszym kandydatem na to jest .netowy CLR (bo wydaje mi się być lepiej pomyślany od javy, cóż chłopaki piszący założenia CLRa mogli uczyć się na błędach javy i wygląda na to że nieźle im to wyszło. Nie wiem jak parrot - teoretycznie jest pod to sporo języków ale czy to ma faktycznie ręce i nogi to chyba jeszcze nikt specjalnie nie sprawdzał. Pythonowy vm wydaje mi się na razie nie spełniać jednego bardzo istotnego założenia - brak wielowątkowości (mówię tu o podstawowym cpythonie). No ale zobaczymy jak się rozwinie pod skrzydłami Googla.
Zauważyliście że to już druga próba offtopicu? ;)
<troll>A może Team Foundation Server (TFS) ? :P</troll>
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Bałagan » Systemy kontroli wersji
Wygenerowano w 0.034 sekund, wykonano 66 zapytań