Bazaar 2.1.0

Byla vydána verze 2.1.0 systému pro správu verzí Bazaar. Zaměřuje se převážně na opravy chyb a čištění kódu. Přináší také například snižení paměťových nároků spousty operací a několik dalších novinek.

23.2.2010 07:13 | Tomáš Heger (geckon) | Nová verze

Komentáře

[alblaho]

Bzr používám na jeden svůj projekt a spokojenost. Jeho největší výhodu vidím v tom, že má ovládání maximálně kompatibilní se SVN.

Ale na vrcholu potravního řetězce je git, ovšem ovládnout ho mi trvalo nějakou chvíli.

[cronin]

Ja som bol velmi odmietavy k DVCS celkovo dlhu dobu. Potom ma okolnosti prinutili objavit Mercurial, od ktoreho som presiel ku Git-u. Ano, chvilu mi trvalo, kym sme sa spriatelili. Momentalne vsak mozem len tazko pochopit, ako som viac ako desatrocie mohol vyvijat software bez Git-u. Cim ale netvrdim, ze centralizovane VCS nemaju svoje miesto. Kto sa raz pokusil nasadit Git v enterprise prostredi, urcite chape silne stranky, ktore ma Subversion.

[Daniel Kvasnička ml.]

Co te vedlo k opusteni Mercurialu ve prospech Gitu?

[Tarmaq]

mozna ten hype kolem Gitu ;]

[alblaho]

Já znám Mercurial ze všech vcs nejmíň, ale tuším, že je hodně podobný tomu Bazaaru. To jest, je to takové verzovátko na půl cesty mezi centralizovaným a distribuovaným, člověk s tím pracuje jako s vylepšeným SVN.

Git je naproti tomu úplně jiný, distribuovaný až do morku kostí a skutečně tvrdě optimalizovaný na vytváření větve pro každou blbost. Ovšem přechod ze SVN je pak o to těžší.

[Daniel Kvasnička ml.]

No ja prave premyslim, ze bych nejaky DVCS zacal pouzivat a jsem prave zatim vic naklonen k Mercurialu. Jednak kvuli podobnosti command setu s nedistribuovanymi predchudci a pak taky kvuli lepsi podpore v IDEs. NetBeans maji podporu vestavenou, plugin pro Eclipse je udajne vyrazne vyvinutejsi pro Mercurial nez ten pro Git. Navic pokud vim, Git se musi ve windows pouzivat pres Cygwin. Ja Win nepouzivam, me je to fuk. Ale kdybych delal na projektu, do ktereho bych chtel zahrnout lidi bez ohledu na "vyznani", tak Hg je v tomhle podle me lepsi.

A co se tyka distribuovanosti, tak podle me Git i Hg tu zakladni myslenku cti velmi slusne -- implementacni detaily me nezajimaji. Zajima me, jaky DVCS ma lepsi ucici krivku, neni prekombinovany/nepotrebne komplexni, je rychly, ma lepsi podporu toolu, luxusni srozumitelnou dokumentaci a v neposledni rade dostupne slusne webove sluzby pro open i closed projekty (minimalne Bitbucket pro Hg je velmi pekna vec, ale Git tu asi diky te hype bude napred...)

Taky me u Hg imponuje, ze hodne produktu ze sveta Javy ho pouziva (proto taky asi nativni podpora v NetBeans).

Na druhou stranu... jaka je absolutni killer feature DVCS pro one man show projekty, kdy autor pracuje s pocitacem, ktery je prakticky neustale v siti a tedy se nevyskytuji situace, kdy by si potreboval changesety commitovat "do supliku"?

[alblaho]

Mercurial si vybrali v Sunu a používá ho i Mozilla. Takže je to dobrá volba, asi lepší než BZR.

Dle mé zkušenosti nemá cenu git používat jinak než z příkazové řádky. Ta je neskutečně mocná a velmi pohodlná, každý plugin do IDE přináší jen část funkcionality, případně za cenu složitého GUI.

[Daniel Kvasnička ml.]

každý plugin do IDE přináší jen část funkcionality, případně za cenu složitého GUI.

Tu cast funkcionality, kterou clovek pouziva casto. Ten zbytek nema vubec smysl, aby tam byl, kdyz se pouziva obcas. A predstava, ze budu kvuli kazde VCS akci prepinat z Eclipse do konzole a zpet, je silena. Produktivita se rovna nule. Prochazeni historie a diffy v konzoli bez jakekoliv navaznosti na IDE?

[Ladicek]

To je v zásadě blábol. Používám IntelliJ IDEu, která měla vždycky nejlepší GUI pro SVN, a tak nemám důvod se domnívat, že její GUI pro Git za nějakým jiným výrazně zaostává. Přesto jsem velmi rychle začal veškerou práci s Gitem dělat v konzoli – a důvodem rozhodně nebylo to, abych snížil produktivitu. K Gitu se univerzální GUI IMHO udělat nedá, nanejvýš jakási aproximace pro lidi zvyklé na SVN. Procházení historie a diffy fungují v IDE výborně – ale třeba větvení je pěkně neohrabané (stačí se podívat na způsob, jak zjistit aktuální větev), úplně chybí zjišťování novinek ve vzdálených repozitářích, a možná bych si vzpomněl ještě na pár dalších věcí.

Stručně řečeno: je to jiné. Je to lepší.

[Daniel Kvasnička ml.]

Ty dva prispevky tady pod sebou dokazuji dve veci

1. Nekomu to terminalove reseni asi fakt vyhovuje.

2. Na povestech o misty az prilisne komplexite Gitu neco bude

[Ladicek]

Git není komplexní, Git je maximalistický

Ne, vážně: na Gitu nesnáším jeho uživatelské rozhraní, evidentně vyvíjené příšerně živelně. To je ukázkový příklad nekonsistence. Na druhou stranu, když jsem naposledy koukal na Hg, tak pro změnu historie (rebase např.) se musel instalovat nějaký plugin, a to jsem si řekl, že tudy fakt ne. S Gitem mám celkem slušnou jistotu, že když něco chci, tak to jde (i když občas nadávám, rozmazlen, že to nejde přesně tak, jak bych v tu chvíli já chtěl ).

[zoul]

Mně přijde Git po chvilkovém zacvičení velmi jednoduchý. Používám klonování repositories, občas něco pushnu, trochu větvím, merguju a rebasuju, samozřejmě commit, občas stash.

Fantastická věc je staging, či jak se tomu říká. Člověk může udělat víc změn najednou (čemuž se v laufu těžko ubrání) a pak commitovat po kouskách. S pomocí stash --keep-index může jednotlivé patche vyzkoušet samostatně ještě před commitem, což je krása.

Složitější věci zatím moc nechápu, ale to přijde časem. Git je investice, podobně jako třeba Vim nebo ostatně celý Unix. Je možné, že ovládání vypadá zpočátku divně, ale teď už mi přijde naprosto přirozené.

[Ladicek]

Ale jo, já už to taky vcelku zvládám, ale ta živelnost je prostě znát. Staging je super – ale teprve tehdy, když si uvědomíte, že pod slovy stage, index a občas i cache (git rm --cached, git diff --cached) se myslí to samé

[Daniel Kvasnička ml.]

Jinak receno: co by me melo primet zvolit Git misto Hg, kdyz Hg zvlada v zasade to same a komplexita Gitu je takova, ze se k nemu GUI udelat poradne neda... Ja jsem minimalista. Nemam rad nastroje, ktere delaji vic, nez co po nich chci a nejsou schopne si to obhajit nicim jinym, nez bigbangovskym "because we can!!" ...coz nutne netvrdim, ze Git je. Jen mi to tak pripada.

[alblaho]

Ale samozřejmě!

Nejvíc teď dělám v Javě, tam to bez IDE nejde. Když chci ale verzovat, dám ALT+TAB a přepnu se do terminálu, kde všechno vyřídím z řádky mnohem rychleji, než bych se proklikal gui.

Základem je obarvený diff (ten lze v gitu zapnout velice jednoduše, v SVN si člověk musel vypomoct skriptem volajícím colordiff). GUI se samozřejmě nebráním git difftool umí pustit k3diff, meld, etc. Když mi to větvení přerůstá přes hlavu, tak graf historie prohlížím v gitk.

Důležité je, že takto jsem schopen efektivně verzovat ať dělám tu Javu v Netbeans, Python v Geditu nebo JavaScript ve vimu.

[Jakub]

Mercurial si vybrali v Sunu a používá ho i Mozilla. Takže je to dobrá volba, asi lepší než BZR.

To jako proto, ze to pouziva Sun a Mozilla? Bazaar zase pouziva treba MySQL a GNOME.

[alblaho]

Reference jsou důležité. GNOME zcela jistě používá Git. Díky podpoře Sunu mají Netbeans nativní podporu Mercurialu.

Bazaar logicky používají Ubuntu-specific projekty a ano, na launpadu teď hostují i Mysql.

[Jakub]

Sranda je, ze Sun ten Hg aspon na OpenSolarisu moc distribuovane nepouziva. Resp. je povolena pouze linearni historie.

[pavlix]

Pochybuju, že by se gnome vůbec dal uhájit na bazaaru. V bazaaru mě otravovala pomalost i při extrémně malých projektech jako byly hříčky do školy.

Jo... někde se psalo, že kucí zapracovali na výrazném zrychlení. Jenže to se psalo i o Vistách, že.

[Lukáš Zapletal]

Mercurial si vybrali v Sunu a používá ho i Mozilla. Takže je to dobrá volba, asi lepší než BZR.

Dle mé zkušenosti nemá cenu git používat jinak než z příkazové řádky. Ta je neskutečně mocná a velmi pohodlná, každý plugin do IDE přináší jen část funkcionality, případně za cenu složitého GUI.

Asi lepší? Co je to za argumentaci? Bazaar zase používá Canonical a spoustu dalších projektů. Jinak pěkné srovnání je na wikině Bazaaru. Součástí Bazaaru je i GUI.

[Michal Vyskočil]

Na druhou stranu... jaka je absolutni killer feature DVCS pro one man show projekty, kdy autor pracuje s pocitacem, ktery je prakticky neustale v siti a tedy se nevyskytuji situace, kdy by si potreboval changesety commitovat "do supliku"?

Tak třeba s DCVS se můžeš rozhodnout si projekt přetáhnout na notebook a v klidu si na něm pracovat kdekoli bez připojení k síti a posléze si změny přetáhnout zpět.

Nicméně to je jen důsledek té pravé zabijácké vlastnosti - DCVS nerozlišují mezi serverovou a klientskou částí stromu, takže otázka nezní proč DCVS, ale proč proboha CCVS?

[xm]

Bazaar (a Mercurial) nejsou žádná "verzovátka na půl cesty", ale naprosto plnohodnotné distribuované VCS minimálně na stejné úrovni jako Git (v něčem jsou oproti Gitu dokonce lepší)! Takovýhle stupidní FUD si nechte od cesty, když ty nástroje neznáte.

To že toho umí oproti Gitu víc a třeba Bazaar umožňuje i "simulovat" některé aspekty centralizovaných VCS rozhodně není na škodu a nedělá to z nich žádné kočkopsy, základ je distribuované VCS až do morku kostí.

[Jakub]

Presne tak, Bazaar je plnohodnotny DVCS, ktery se da bohuzel pouzivat nedistribuovanym zpusobem. Rozhodne bych si dovedl predstavit orezanou verzi, ktera by nic takoveho neumela a nutila tak vsechny vyvojare myslet a pracovat distribuovane. To ale nic nemeni na tom, ze se jedna o plnohodnotny DVCS, kdyz jej tak pouzivate.

[alblaho]

Ten termín jsem použil asi nešťastně, zní zbytečně provokativně. Jak jsem řekl, bazaar aktivně používám, hg znám jen teoreticky. A největší výhoda BZR je v tom, že je to SVN na steroidech.

Plnohodnotná DVCS to jistě jsou. Každé DVCS umí z definice pracovat i jako centralizované VCS, ne?

A v čem je tedy BZR lepší než git, kromě toho že je jednodušší?

[Radim Kolář]

To ze je BZR jednodusi je vyrazna vyhoda, je totiz mnohem vetsi riziko ze nekdo v GIT neco udela spatne. Tady nejak detailne do toho gitu lidi moc nevidi.

Sam pouzivam BZR z duvodu:

1. jednoduchost,
2. beha na windows,
3. pluginy,
4. staci mu i sftp server,
5. dobry www revision browser (lepsi nez svn/git)

git je prilis slozity na ovladani. Taky se mi libi jazz VCS.

[Daniel Kvasnička ml.]

Me se na Jazzu libi bezkonkurencne luxusni integrace s Eclipse + ten jejich build server. Jinak ale na muj vkus az prilis casto musim klikat na "Repair metadata"... :/ a nechat bezet build engine nad stejnou workspacou, nad kterou pracuju, tak to je zaruceny recept na bordel ve workspacach celeho tymu

Taky mi nikdo z kolegu nebyl schopen vysvetlit, jak udelat vetev ci se do ni switchnout bez restartu Eclipse a vyberu jineho WS.... ale to predpokladam, ze je spis neznalost. Ze by to tak bylo, to mi pripadne zcela mimo zdravy rozum...

[Radim Kolář]

Jakou verzi Jazzu mate? my 2.0.0.1 a s tim repair metadata problem nemame, jen bylo potreba zvysit permgensize u Eclipse aby to nepadalo.

--launcher.XXMaxPermSize
350m
-vmargs
-Dosgi.requiredJavaVersion=1.5
-Xms200m
-Xmx600m

Ale mame cely Eclipse vcetne birt, Optim a infosphere pluginu. Eclipse je Galieo (tam se jazz musi doinstalovat rucne podle navodu - instalak to neumi).

build engine ma mit svuj workspace - aspon to tak doporucuji v dokumentaci.

Jak udelat vetev? proste si to vyexportujte jako dalsi eclipse projekt.

[Daniel Kvasnička ml.]

Mame 2.0.0.

build engine ma mit svuj workspace - aspon to tak doporucuji v dokumentaci.

K tomu jsem casem taky dosel, no

Jak udelat vetev? proste si to vyexportujte jako dalsi eclipse projekt.

Coz je ovsem naprosto silene. V SVN proste udelam v repository vetev a pak kdyz chci, switchnu si dany projekt do jakekoliv z vetvi ci zpet. A predpokladam, ze i DVCS jako Hg ci Git to maji podobne... Delat kvuli tomu dalsi projekt je psycho.

[Jakub]

Mne se na Bazaaru libi, ze umi verzovat i prazdne adresare. Sice to neni nejaka killer feature, ale nekdy se to muze hodit. Nevim jak je to v Gitu, ale v Hg muze mit repository vic hlav, coz se mi moc nelibi. V Bazaaru mam kazdou hlavu v samostatnem "repository"/adresari, ale chapu, ze zrovna tohle muze byt pro nekoho nevyhoda.

[alblaho]

Těch "víc hlav" je killer fíčura gitu, umožňuje to plynulejší přecházení mezi větvemi. Nicméně chápu, že se to nelíbí každému.

Jinak git prázné adresáře neumí a trochu nepříjemně mě to překvapilo

[qwertzuiop]

Přesně tak. Prej "verzovátka na půli cesty"... To snad není pravda.

[cronin]

Well, na zaciatku to bola potreba (zadana uloha) porovnat tieto dva. Velmi rychlo som zistil dva fakty:

1) Schopnosti Git-u su nadmnozinou schopnosti Mercurialu. Kto chce Git pouzivat jednoducho, moze. Kto chce vyuzivat low-level featury (plumbing) Git-u, opat moze - a z nich sa da poskladat prakticky cokolvek. Mercurial tuto moznost AFAIK neposkytuje.

2) Git je navrhnuty neuveritelne pragmaticky: ak je nejaka cinnost, ktora je obvykla pri praci na sw projekte v suvislosti so zdrojakmi a VCS, Git poskytuje priamociare riesenie, a to tak co sa tyka manipulacie s udami, ako aj vyhladavania vsemoznych typov odpovedi v historii. Ako vravi Bruce Willis v Smrtonostnej pasci II: "Vsetko co napadne nam, moze napadnut aj im." Inak povedane, ak pouzivatel Gitu ma nejaku potrebu cosi vykonat s VCS, prevdepodobne mal tuto potrebu uz niekto pred nim a nastroj uz existuje. Pravda je, ze niekedy nemusi byt zjavny, a to ani po precitani manualu.

[RapMan]

V soucasne dobe taky pouzivam SVN, celkem spokojenost, spolecne s webovym rozhranim gforge. Jediny problem, ktery se mi zatim nepodarilo vyresit, je kdyz bych chtel mit jeden soubor v adresari spolecny ve vice repozitarich.

Napr.

trunk/ProjectFolder/ a tam soubory napr. 1.txt, 2.txt

A vim, ze soubor 2.txt by mel byt vzdycky stejny a aktualizovatelny jako soubor 2.txt v uplne jinem repozitari. Jak toho docilit, umi to SVN? Umi to jiny version management system? Kdyz aktualizuju soubor 2.txt v jakemkoliv projektu, aby se automaticky zaktualizoval i v tech ostatnich.

[stativ]

mrkni na svn externals.

[alblaho]

Obávám se, že s tím ti žádný VCS nepomůže. A když už, tak to bude možná právě ty externals se Subversion.

[Michal Vyskočil]

Pokud netrváš na tom, aby byl ten exterení soubor ve stejném adresáři, tak git má podporu pro submoduly, ale ty mi přijdou dost přes ruku. Alternativní možnost je popsaná v knize Pro Git subtree merging.