A CodePlex.com csapat 25 ezer dollárral támogatta a Mercurial projektet

Microsoft, Windows

A Microsoft CodePlex.com csapata 25 ezer dolláros adományt adott át a Mercurial projektnek. A Mercurial projekt áll a Mercurial névre hallgató, nyílt forrású, keresztplatformos, elosztott verziókezelő rendszer mögött. Az év korábbi szakaszában vezették be a CodePlex-en (a Microsoft nyílt forrású projekt hosting szolgáltatása) a Mercurial-t, mint választható elosztott verziókezelő rendszer opciót a felhasználók számára. Azóta több mint 1500 projekt használja a Mercurial-t.

Noha jelenleg még a Team Foundation Server a legnagyobb mértékben használt verziókezelő rendszer a CodePlex-en, a felhasználók egyértelműen profitálnak abból, hogy projektjeikhez igény esetén használhatják a Mercurial-t. Mivel a Mercurial a CodePlex fontos szolgáltatásává vált, a CodePlex.com csapat örül, hogy támogathatta a projektet.

Matt Mackall, a Mercurial atyja és vezető fejlesztője elmondta, hogy az adomány lehetővé teszi, hogy a következő évben teljes időben dolgozhasson a projekten. Eddig csak szabadidejében dolgozott rajta, de így nem fejlődött a projekt olyan ütemben, mint ahogy fejlődhetett volna. Azzal, hogy teljes időben dolgozhat a projekten, felgyorsulhat a Mercurial fejlesztése.

A részletek itt.

Az utobbi par honapban en is nagyon megkedveltem. Egyszeru, mint a faek, megis komplex dolgokat meg lehet vele csinalni. Nem vagyok nagy hive a parancssoros buzgeralasnak, de a Mercurialt en is gyakran parancssoron keresztul hasznalom.

Ha lehetne valasztani, hogy mire menjen el az a 25 ropi, akkor en a tortoisehg-t irnam at normalis kinezeture (pozitiv peldakent a tortoisesvn-t tudom felhozni).

(Windows-os VisualStudio fejlesztoknek a hgscc es a hgwin kotelezo darabok!!!!)

Subversiont hasznaltam par evig, git-et kiprobaltam, mielott a Mercurialra valtottam.

Szerintem az svn-hez kepest klasszisokkal kenyelmesebb maga a verzio es branch kezeles, a teljesitmenye is jobb.

En ugy latom, hogy a Mercurial es a Git sok szempontbol hasonlo, a git kicsit geek-ebb, alacsonyabb szintu utasitasai vannak, de ugyanakkor feltehetoen gyorsabb.

A Mercurial python-ban keszult a windows hivatalosan tamogatott platform, a Git-et nagyreszt c-ben irtak a windows port kisse mostoha gyerek.

Visual Studio-hoz jo plugint nem talaltam, ami a git-et integralna (ugyanez igaz a bazaar-ra is).

Szoval mindent osszevetve, ha Windows-ra valamilyen dvcs-t szeretnel hasznalni, akkor a Mercurial tunik favoritnak, foleg, ha Visual Studio integracio is kell.

( nevergone v | 2010. 09. 08., sze – 11:55 )

Már kezdtem azt hinni, hogy megszűnt! :)

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

( Joejszaka v | 2010. 09. 08., sze – 12:01 )

Mi a Mercurial előnye mondjuk az svn-hez vagy git-hez képest?

Tobb megoldas is letezik (git eseteben legalabbis; mercurialt csak alapszinten ismerem):

1) Ossze lehet packelni a historyt, maris kisebb lesz (git repack; ill git gc)
2) Shallow clone (git clone --depth N)

Sok esetben egyebkent a teljes history kisebb, mint a kicheckoutolt, legalabbis git eseteben. gc & repack durvan ossze tudja nyomni a dolgokat.

Bizonyara igazad van, de ha egy file teljes historyja kell, akkor mar elofordulhat, hogy a teljes repot kell lecincalni, szoval ezzel csak elmaszatolod a problemat.

Osszessegeben veve engem nem kell meggyozni arrol, hogy jo dolog a git vagy a mercurial. Azzal kapcsolatban viszont vannak fenntartasaim, hogy egy masszivan nagy projektet is kenyelmesen lehet-e vele kezelni.

Egy ilyen masszívan nagy projectet már lehetséges, hogy érdemes szétbontani több repository-ra, elég kevés helyen lehet arra szükség, hogy minden fejlesztő minden részébe dolgozzon. Akár a "git submodules" is segíthet.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Egy masszivan nagy projectnel ha kell egy file historyja, es a history nem lokalisan van, akkor a szervert fogod megdolgoztatni szepen. Az sem biztos, hogy jo otlet.

Es ahogy a kollega irta: ha ennyire nagy a project, esetleg erdemes lenne feldarabolni kisebb reszekre. Megjegyzem egyebkent, el nem tudom kepzelni hogy legyen akkora project aminek teljes historyja egy mai gepnek komolyabb problemat okozna. Persze, egyszer le kell huzni. Nem latom be, az miert okozna problemat.

Mit ertesz egyebkent masszivan nagy project alatt?

Itt van pl a linux kernel, ~300mb kicheckoutolva, ~4.5mb .git, 5 eves history, 110k+ commit. Ez szerintem egy eleg szep meretu dolog.

Persze, akar az egesz OS, userlandel egyutt lehetne egy repoban, ami meglokne egy csoppet ezt. Mondjuk, hasrautes-szeruen, haromszorosara. ~1g checkout, ~15mb history, 300k+ commit. Ez mar masszivan nagy, de nagyon eros a gyanum, hogy meg mindig kenyelmesen kezelheto pl gittel. Felteszem a tobbi dvcs-el is. Maga a history - git eseteben legalabbis - elhanyagolhatoan kicsi sokszor.

git repack. ne kerdezd hogyan, nem tudom. kiprobaltam hogy kicheckoutolom a legelso commitot, es gond nelkul megtette, mint ahogy akarmelyik masikat is. Tehat a teljes history elerheto a 300mbs checkout +4.5mbs .git altal. (Legalabbis random commitokat siman ki tudtam checkoutolni. Bar a 4.5Mb nekem is kicsit kevesnek tunik, meg packelve is - mindenesetre a .git/ konyvtar altalaban kisebb, mint a kicheckoutolt forras, felteve hogy az ember rendszeresen packel. Amit a git egyebkent megtesz magatol is X commitonkent, ha jol remlik)

A teljes linux history (gondolom a BKs idoszak ota), Linus elso commitja szerint 3.2Gb. De akkor meg nem volt eros packing.

Az előbb kíváncsiságból klónoztam a linux repot, és azt mondja, hogy

406236 ./.git
876608 .

Szóval a frissen klónozott repo kevesebb helyet foglal, mint az aktuális work tree, de a ~400 mega a 4.5-től elég messze van.

Nem lehet, hogy a te repod alternates vagy hardlinkelt klón miatt olyan kicsi?

git-et sose próbáltam. olvasgattam, mindenhol azt írták, hogy git beállítása (főleg szerveroldalon) sokkal macerásabb. fícsörök tekintetében meg kb. ugyanannyit tud.

hg egyszerűen belőhető windows-on, vs-sel, innestől nekem nem kell több.

http://img689.imageshack.us/img689/8649/mercurial.png
szerintem.

A decentralizáltság nagy előny tud lenni. Azért is kezdtem el Bazaar használ (Mercurial nagy ellenfele).

A mező közepén a laptoppal, ha szükséged volt a SVN-en 2-3 előbbi verzióra, akkor megszívtad. Nincs Net, nincs korábbi verziók. Most hogy megjelentek a mobilnetek nem annyira gáz.

Továbbá nem szemeteled tele a központi repót a saját mentéseiddel. Ha olyan vagy, hogy minden kis változtatást kommitolsz, akkor előbb-utóbb szép nagy revision listád lesz.
Viszont decentralizált verzió kezelő esetén komitolhatsz maganak lokálisan is és amikor már tényleg tuti a dolog, akkor küldöd fel a központi repoba a végleges cuccot.

Nincs gond abból, ha a fejlesztőknek "játszótér" kell a kísérletezgetéshez. SVN-nél ha nyitsz egy közös branch-ot erre, akkor belerondítanak egymáséba, de a lokális kommit ezt (is) megoldja.
Régebben sokáig bzr-t használtam, most git-et, de úgy tapasztaltam, hogy a maga módján mindegyik több a hg-nél (bzr egyszerűbb, a git gyorsabb).
Persze a legfontosabb az, hogy legalább az egyiket ismerje meg az ember és használja.

-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."

Erdekes iras. Clearcase hasznalokent megsem erzem az atuto erejet. Clearcase alatt hostolhatsz sajat VOB-ot (kvazi repository), lehet snapshot view-d (kvazi checkout), de lehet dinamikus is, amikor a VOB-ban levo view-dat latod a serveren, helyi masolat nelkul.

A 3 utas mergeles minden esetben rendelkezesre all, az ugymond verzio-kezelo rendszer osszes lehetosege adott. Komoly szopasrol nem hallottam mergelesnel, pedig mind szoros egyuttmukodesben, mind pedig fuggetlen agon valo munkaban hasznaltam.

Elhiszem hogy egy CVS-hez vagy SVN-hez kepest ez uberfranko (az emlitett peldak lattan siman a rohogogorcs kapott el), de egy normalis, kereskedelmi verziokovetohoz kepest nem igazan latom a hatalmas ujdonsagot, hiaba a Zen. Lehet, hogy mar agymosott vagyok.

Nyilvan a tureshatar mashol van kis es nagy letszamnal. Hobbiprojekthez en sem azt hasznalom :-)

A cikkben rossz verziokovetoket hozott fel a szerzo es azokhoz hasonlitotta a Mercurialt, majd a cikk vegen levont kovetkeztetes nekem erosnek tunik. Ezert erdekel, hogy valoban jol latja a kulonbseget, vagy pusztan benyalta a szokasos opensource szinvonalbol eredo altalanositast.

Ritkan szokott erdekelni ki mekkora nagysag, attol meg tevedhet; mintha a cikk eleje is pont igy indult volna. Elfogultsagom nincsen, sok gyakorlati oldalban nem szeretem a Clearcase-t, de a mostani kerdes elmeleti megkozelites, ergo sem az ara, sem pedig a napi implementacios nyugok nem izgatnak kulonosebben.

En nem hasznaltam ClearCase-t, de ismerosom szerint egeszen az ujabb verziokig Windows-on szinte hasznalhatatlanul lassu volt...

Masfelol meg a ClearCase-t nyilvan nem feature listaban, hanem konnyebb telepithetotesegben, adminisztracioban es alacsonyabb arcedulaban veri romma a Mercurial. A kerdes igazabol az, hogy kinek mi a fontos. A ClearCase nyilvan egy szigoru workflow-t hasznalo, jol specifikalt fejlesztesekkel operalo nagyceg szamara nagyon vonzo, de kisebb csapatoknak egesz egyszeruen brutalis overkill, mivel nem hasznalt funkcionalitasert fizetnek. Raadasul -szinten hallomasbol- ugy ertesultem, hogy a ClearCase adminisztracio egy kulon szakma. Ehhez kepest az orok rivalis Perforce maga az egyszeruseg (ezt viszont mar en is szemelyesen lattam).

Nincs olyan, hogy legjobb version control eszkoz. Adott feladathoz, fejlesztocsapathoz, fejlesztesi szokasokhoz kell kivalasztani a legjobban alkalmazhatot.

A kerdes nem ez volt, sot meg az sem hogy melyik a jobb. Ne vesszunk el abban hogy kinek mi a fontos, mi az abszolut igazsag mi lassu mi nem, mi mennyibe kerul, stb.

A kerdes az volt, hogy az a kovetkeztetes amire Joel kilyukadt (ti. hogy a changesetes modell mennyivel szuperebb a verzios modellnel), az mennyi igazsagot tartalmaz. Elvi sikon, nem pedig olyan programok eseteben amik mondjuk implementacios betegsegekben szenvednek. Kulonosen annak fenyeben hogy egy _jo_ verziokoveto rendszerhez hasonlitod a changesetes Zen filozofiat es nem az SVN-hez. A peldak amiket hozzott, sajnos csak az SVN vilagbol erkeztek, az pedig gyakorlatilag egy vicc egy rendes verziokovetohoz kepest.

Ezert vontam ketsegbe a cikkben levo kovetkeztetes jogossagat, de nagyon szivesen hallanam olyan velemenyet is, aki mindkettot hasznalta erdemben. En sem ilyen vagyok, en foleg Clearcase-t hasznaltam, CVS-t es SVN-t mar ritkabban, a git es mercury pedig teljesen kimaradt; ezert is erdekel a dolog.