Distribuované verzovací systémy: Mercurial – úvod

6. 12. 2011 | František Kučera | Návody | 10136×

Předchozí dva díly tohoto seriálu byly věnované teorii distribuovaných verzovacích systémů. Dnes se konečně podíváme prakticky na jeden z nich – Mercurial (zkráceně Hg). Kromě úplných základů (přidávání souborů pod správu verzí, mazání, přejmenovávání…) si také ukážeme, jak se vracet ke starším verzím a jak si verze pro větší přehlednost označovat pomocí štítků.

Obsah

• Instalace a nastavení
• Začínáme s verzováním
  • Vytvoření úložiště a přidání souborů pod správu verzí
  • Ignorování nežádoucích souborů
  • Postoupení první verze do úložiště
  • Verzování /etc
  • Klonování úložiště
  • Čí je tohle práce?
  • Webový pohled na úložiště a Kompare
  • Přesouvání souborů
  • Mazání souborů
  • Návrat do minulosti
  • Štítky
• Závěr
• Odkazy a zdroje

Instalace a nastavení

Instalace programu je v linuxových distribucích jednoduchá, použijeme balíčkovací systém a Mercurial si nainstalujeme např. jedním z těchto příkazů:

aptitude install mercurial    # Debian/Ubuntu
yum install mercurial         # Fedora/RedHat

Příkaz pro práci s Mercurialem se jmenuje hg a mělo by nám fungovat doplňování a napovídání tabulátorem. Např. napíšeme hg com a stiskneme tabulátor a doplní se na hg commit.

Globální nastavení Mercurialu se nachází v souboru /etc/mercurial/hgrc. Zde nic měnit nemusíme. Jediné, co bychom si měli nastavit, je jméno v našem uživatelském konfiguračním souboru v ~/.hgrc – sem zadáme něco jako:

[ui]
username = Jméno Příjmení <jmeno@example.com>

Při commitování změn se pak toto použije jako jméno autora.

Kromě globálního a uživatelského konfiguračního souboru existuje i nastavení pro jednotlivá úložiště – nachází se uvnitř nich v souboru .hg/hgrc.

Začínáme s verzováním

Dejme tomu, že píšeme článek, diplomku, nějaký svůj program/skript… přestože to nepotřebujeme nikde vystavovat nebo s někým sdílet, může se nám hodit verzovací systém. Možná se vám už taky někdy stalo, že jste něco přepsali a pak jste si vzpomněli, že formulace, kterou jste tam měli ještě před pár dny byla lepší. Nebo třeba jen chcete sledovat, jak vám jde práce hezky od ruky – vidět kolik textu kdy přibylo. Místo toho, abychom si každý týden/den kopírovali vytvořené soubory do nějak pojmenovaného adresáře je začneme verzovat – je to snadné, takže se nemusíme bát použít verzování i v banálních případech – není to pověstný kanón na vrabce – je to naopak jednodušší a můžeme u toho udělat méně chyb, než kdybychom soubory zálohovali/verzovali ručně kopírováním.

Vytvoření úložiště a přidání souborů pod správu verzí

Otevřeme si terminál a vstoupíme do složky se soubory, které chceme verzovat, a zadáme příkaz:

$ hg init

Příkaz nic nevypíše (to je v pořádku) a vytvoří nové mercurialové úložiště – vznikne adresář .hg. Úložiště je zatím prázdné. Následujícím příkazem zjistíme aktuální stav:

$ hg status 
? index.xhtml
? soubor.txt
? video.ogv

Otazník před názvem souborů znamená, že tyto soubory nejsou zatím verzované. Soubory si tedy přidáme pod správu mercurialu:

$ hg addremove 
adding index.xhtml
adding soubor.txt
adding video.ogv
$ hg status 
A index.xhtml
A soubor.txt
A video.ogv

U souborů je teď příznak A a to znamená, že jsou čerstvě přidané a když zadáme hg commit, uložíme je trvale do mercurialu jako novou verzi.

Jenže teď si uvědomíme, že video verzovat nechceme – naštěstí se nic nestalo a můžeme se vrátit zpět:

$ hg revert --all
forgetting index.xhtml
forgetting soubor.txt
forgetting video.ogv
$ hg status 
? index.xhtml
? soubor.txt
? video.ogv

A přidáme soubory raději jednotlivě – jen ty, které skutečně chceme verzovat:

$ hg add soubor.txt index.xhtml 
$ hg status 
A index.xhtml
A soubor.txt
? video.ogv

Ignorování nežádoucích souborů

Abychom na to nemuseli pokaždé myslet, vytvoříme si seznam souborů, které se nemají verzovat:

$ echo "video.ogv" >> .hgignore
$ hg add .hgignore
$ hg status 
A .hgignore
A index.xhtml
A soubor.txt

Nežádoucí soubory nám už nepřekáží ve výpisu hg status a nestane se nám, že bychom je omylem postoupili do úložiště (to bychom museli udělat záměrně: hg add video.ogv, ale hromadné přidání/odebrání pomocí hg addremove je bude ignorovat). Samotný soubor .hgignore je rovněž verzovaný – to je dobré jednak proto, že seznam se může v čase měnit (např. soubory, které jsme chtěli ignorovat v prvních verzích teď chceme verzovat a naopak), a jednak proto, že tento seznam se bude šířit společně s ostatními soubory – když uděláme push nebo pull, seznam ignorovaných souborů bude všude stejný.

Soubor .hgignore může obsahovat jak regulární výrazy, tak obyčejné vzory jako v shellu – např. *~. Vždy jeden vzor na jednom řádku. Obvykle budeme ignorovat celé adresáře jako dist/*, build/* a záložní soubory.

Postoupení první verze do úložiště

Ještě jednou si pro jistotu vypíšeme hg status a když jsme s výsledkem spokojeni, můžeme vytvořit svoji první verzi:

$ hg commit

Otevře se nám textový editor, do něj napíšeme popis změn, které daná verze přináší – první řádka by měla být výstižná a stručná (zobrazuje se v krátkých výpisech historie) a na dalších řádcích se můžeme rozepsat klidně trochu víc. Hodně záleží co a pro koho verzujeme – když si verzujeme jen tak pro sebe, asi tam nebudeme psát moc dlouhé romány, ale když pracujeme v týmu, je dobré napsat srozumitelný popis změn (ne každý chce číst zdrojový kód a dělat si diff), nějaké vzkazy pro člověka, který bude dělat revizi naší práce, a pokud používáme systém na správu požadavků/chyb, měli bychom zadat i čísla úkolů, které jsme zde řešili (obvykle se před číslo dává # a systémy jako Trac z toho pak umí udělat odkaz na daný úkol). Platí zde podobné zásady jako pro komentáře v kódu: neměli bychom psát až tak, co jsme udělali (např. „do metody xyz() jsem přidal a = b + 10;“ – to je vidět z diffu, tudíž zbytečná informace), ale proč jsme to udělali a jaký to má smysl (např. „oprava chyby: zdvojování teček v protokolu SMTP“ a ideálně i její #číslo).

Zprávu nemusíme psát do editoru a můžeme ji uvést na příkazové řádce:

$ hg commit -m „Popis změn…“

Také můžeme postoupit jen konkrétní soubory, přestože jich bylo přidáno či změněno více:

hg commit index.xhtml soubor.txt

A když si to úplně na poslední chvíli rozmyslíme, stačí ukončit editor a žádnou zprávu nepsat – Mercurial to pochopí:

abort: empty commit message

a žádnou verzi nevytvoří.

Verzování /etc

Kromě zdrojových kódů nebo různých vlastních souborů můžeme tímto způsobem verzovat i konfiguraci našeho počítače v /etc:

# cd /etc
# hg init
# chown root:root .hg/
# chmod 700 .hg/
# hg addremove
# hg commit -m „prvotní verze konfigurace“

Na chmod a chown nesmíme zapomenout – jinak by se mohlo stát, že se k souborům, které může normálně číst jen superuživatel, dostane přes verzovací systém i někdo jiný.

Verze pak můžeme vytvářet při každé ruční změně konfiguračních souborů, případně si tento proces automatizujeme programem etckeeper (verzuje /etc v pravidelných intervalech a při aktualizacích balíčků).

Klonování úložiště

Zatím jsme se pohybovali pouze mezi pracovní kopií (normální soubory v adresáři, které upravujeme) a místním úložištěm (uvnitř adresáře .hg, spravované Mercurialem, zde nic ručně neupravujeme, maximálně konfigurační soubor .hg/hgrc) Pro připomenutí jeden obrázek z minula:

Jelikož se obvykle verzují důležité a pracně vytvořené věci, bylo by škoda o ně přijít třeba při havárii pevného disku. Proto je potřeba zálohovat – s verzovacím systémem to jde velice snadno.

Přepneme se do adresáře na externím nebo třeba síťovém disku a naklonujeme sem svoje dosavadní úložiště:

$ cd /mnt/externí-disk/
$ hg clone ~/diplomka/
destination directory: diplomka
updating to branch default
3 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd diplomka

Máme teď kompletní kopii náší práce včetně všech předchozích verzí. Vazba na původní úložiště (odkud jsme klonovali) zůstává zachována – najdeme ji v konfiguračním souboru:

$ cat .hg/hgrc 
[paths]
default = /home/franta/diplomka

Díky tomu nám budou fungovat příkazy hg push a hg pull, pomocí kterých můžeme „synchronizovat“ obě úložiště. Můžeme tedy pracovat střídavě v obou úložištích a třeba i na více počítačích současně (nosit si externí disk s sebou). A zároveň máme ve věcech pořádek – vždy víme, která verze je aktuální, a nestane se nám, že bychom si omylem soubory přepsali nějakou špatnou verzí – i kdyby se nám to stalo, vždy se můžeme vrátit zpět a chybu napravit.

Před stažením změn z druhého úložiště (hg pull) se můžeme podívat, jaké změny čekají na druhé straně:

$ hg incoming 
comparing with /home/franta/diplomka
searching for changes
changeset:   1:87df11cb506b
tag:         tip
user:        František Kučera <franta-hg@example.com>
date:        Thu Nov 24 15:18:08 2011 +0100
summary:     Druhá verze

Vidíme, že provedením hg pull si stáhneme jednu sadu změn, víme kdo ji vytvořil, kdy a vidíme její popis. Pustíme tedy hg pull a následně hg update (tím aktualizujeme pracovní kopii na poslední verzi).

Obdobným způsobem fungují příkazy hg push a hg outgoing, akorát v opačném směru.

Čí je tohle práce?

Příkazem hg log si vypíšeme historii celého úložiště:

$ hg log
changeset:   1:87df11cb506b
tag:         tip
user:        František Kučera <franta-hg@example.com>
date:        Thu Nov 24 15:18:08 2011 +0100
summary:     Druhá verze

changeset:   0:01c1e32a34f5
user:        František Kučera <franta-hg@example.com>
date:        Thu Nov 24 14:13:04 2011 +0100
summary:     Moje první verze

A příkazem hg annotate index.xhtml zjistíme, z jaké verze pocházejí jednotlivé řádky daného souboru – každý řádek začíná krátkým číslem verze (v našem případě by to byly 0 a 1, protože máme zatím dvě verze a čísluje se od nuly). Díky tomu víme, jak je který řádek starý a který autor ho má na svědomí. Užitečné je to zvlášť při vývoji softwaru – když nějaké části kódu nerozumíme, můžeme jít přímo za konkrétním kolegou a zeptat se, co tím myslel. Ostatně v Subversionu se tato funkce jmenuje svn blame (obvinit).

Pro podrobnější výpis použijeme hg annotate s volbami --changeset a --user.

Webový pohled na úložiště a Kompare

Práce na příkazové řádce je sice fajn, ale některé věci jsou přeci jen lépe vidět v GUI. K pokročilejším externím nástrojům se dostaneme v příštím díle – zatím si vystačíme se samotným Mercurialem. Ten disponuje vestavěným HTTP serverem, který zpřístupní dané úložiště.

$ cat ~/bin/hg-náhled
#!/bin/bash
konqueror http://localhost:8000/?style=gitweb &
hg serve -p 8000

Pomocí tohoto skriptu si spustíme www prohlížeč a HTTP server a podíváme se, co je v daném úložišti. Přehledně vidíme všechny verze, můžeme si rozkliknout jednotlivé změny a rozdíly v souborech. K dispozici je i vyhledávání, stromový pohled a další funkce.

Tím můžeme zkoumat změny, které byly již postoupené do úložiště. Pro porovnání pracovní kopie s úložištěm se nám bude hodit následující skript:

$ cat ~/bin/hg-porovnej
#!/bin/bash
hg diff | kompare -o -

Tento příkaz je dobré spustit před hg commit a podívat se, co přesně se chystáme odeslat – vidíme nové řádky (modře), změněné (červeně) a smazané (zeleně).

Přesouvání souborů

Při přesouvání souborů je lepší použít příkazů Mercurialu – místo:

$ mv soubor.txt Soubor.TXT
$ hg status 
! soubor.txt
? Soubor.TXT

použijeme raději:

$ hg mv soubor.txt Soubor.TXT
$ hg status 
A Soubor.TXT
R soubor.txt

a soubor se nejen přesune/přejmenuje, ale zároveň se i správně připraví na postoupení do úložiště: původní soubor je ve stavu R (ke smazání) a nový ve stavu A (přidání).

Mercurial si navíc pamatuje, že Soubor.TXT vznikl ze soubor.txt (Soubor.TXT má nastaveno parent 1 soubor.txt@87df11cb506b), takže je historie zachována a lze sledovat změny (např. pomocí hg annotate) zpětně i do dob, kdy se soubor ještě jmenoval jinak. Což by nemuselo fungovat, kdybychom jeden soubor jen smazali a druhý vytvořili bez vědomí Mercurialu (pak by to byly dva úplně jiné nezávislé soubory).

Naštěstí Mercurial je celkem inteligentní, takže se dokáže vypořádat i s tím, když soubor přejmenujeme bez něj a pak dáme hg addremove:

$ hg addremove 
removing soubor.txt
adding Soubor.TXT
recording removal of soubor.txt as rename to Soubor.TXT (100% similar)

Nicméně jistější je ten první způsob (hg mv), protože pak můžeme soubor v jednom kroku přejmenovat i měnit jeho obsah a přesto se neztratí informace, že jde o tentýž soubor.

Mazání souborů

Pokud soubor smažeme obyčejně pomocí rm, Mercurial si všimne, že chybí:

$ rm Soubor.TXT
$ hg status 
! Soubor.TXT

Ale při následujícím hg commit se toto smazání nijak neprojeví. Je to stejné, jako když vytvoříme nový soubor a nepřidáme ho pod správu verzí pomocí hg add. Aby se smazání uložilo v rámci dané verze, musíme dát hg remove (místo obyčejného smazání, nebo dodatečně po něm):

$ hg rm Soubor.TXT
$ hg status 
R Soubor.TXT

Při postoupení změn se tento soubor v úložišti smaže (staré verze tam samozřejmě zůstanou a můžeme se k nim kdykoli vrátit).

Návrat do minulosti

Jedním z důvodů, proč verzovací systémy používáme, je cestování v čase – můžeme se vracet ke starým verzím souborů.

Pomocí hg up -r ? se vrátíme k vybrané verzi (její číslo zjistíme z hg log):

$ hg up -r 0
2 files updated, 0 files merged, 2 files removed, 0 files unresolved

A pomocí hg up bez parametru aktualizujeme pracovní kopii na poslední verzi, která je v úložišti.

Pro označení verzí můžeme samozřejmě používat i hashe:

$ hg up -r 7f906c7d62cc
1 files updated, 0 files merged, 1 files removed, 0 files unresolved

Následujícím příkazem pak zjistíme, kde v čase se právě nacházíme:

$ hg identify 
7f906c7d62cc

Štítky

Odkazovat se na verze pomocí podivných čísel je dost nepohodlné. Proto existují tzv. štítky, kterými si můžeme jednotlivé verze označit. Dejme tomu, že verze 4:7f906c7d62cc je nějakým způsobem zajímavá (např. program v této verzi jde nejen zkompilovat, ale i spustit), tak si ji pojmenujeme:

hg tag --rev 4 "tohle funguje"

A pak se na ni můžeme odkazovat tímto jménem místo čísla:

hg up "tohle funguje"

Všechny štítky si vypíšeme příkazem:

$ hg tags 
tip                                8:89a449ab3cb0
tohle funguje                      4:7f906c7d62cc
třetí verze                        3:07708ca1e12f

A kromě toho je i přehledně vidíme ve webovém rozhraní.

Závěr

Dnešní úvod do Mercurialu byl pro některé možná příliš podrobný a zdlouhavý, ale článek by měl sloužit i těm, kteří zatím žádný verzovací systém nepoužívali a chtěli by s tím začít. Příště se budeme věnovat více týmové práci (stahování ze vzdálených úložišť i zpřístupnění vlastního úložiště pomocí různých protokolů ostatním) a práci s větvemi. Také si ukážeme některé GUI programy, protože příkazová řádka není všechno.

       

Komentáře

[maleprase]

commitovani - hrozny slovo

[xkucf03]

Já vím. V obrázku jsem to přeložil jako „postoupení změn“ – nicméně v textu jednou „commitování“ je (dal jsem to aspoň kurzívou, vím že to do češtiny nepatří). Přijímám návrhy na lepší překlad Jinak se asi budu držet toho „postoupení změn“ (ale ideální by bylo jedno slovo).

[linear]

"zapikolování změn".

[Luboš Doležel (Doli)]

Jsem pro zachovat commitování. Postoupení změn bych nevěděl, co je.

[kralyk z abclinuxu]

No, anebo tam prostě nechat 'commit'.

Při commitování změn se pak toto použije jako jméno autora. → Při commitu změn se pak toto použije jako jméno autora.

[kaja gottzilla]

Ma dneska vyznam pouzivat nieco ine ako git ?

V com je toto lepsie ako git ? Co som pocul tak to poizivaju jedine preto lebo toto ma krajsie gui pre widly ako git.

[alfonz mucha]

No má, npř. git může být i docela složitý, stačí se podívat na bzr a hg kolik věcí udělají automaticky oproti gitu.

takový nástřel jak by to mohlo vypadat když by to byly auto git - auto na závody bzr a hg - prostě takový dnešní "combík"

[Luboš Doležel (Doli)]

stačí se podívat na bzr a hg kolik věcí udělají automaticky oproti gitu

A jaké věci to jsou? (Neprudím, zajímá mě to)

Uznávám, že třeba mazání vzdálené větve není zrovna logické:

git push origin :větev

[pavlix]

Srovnání s auty neřeším, obvykle nevycházejí.

Kecy nemaj cenu, nás zajímají konkrétní příklady. Pokud bych měl zahodit osvědčenou věc jako je git, která se IMO dá používat jak jednoduše, tak i složitě, tak k tomu musí být pádný důvod, ne plané řeči.

Kdybych chtěl „kombíka“, tak bych si pořídil windows a správu verzí bych řešil vytvořením nového adresáře (samozřejmě myší), jako to dělají „všichni normální lidi“.

[kralyk z abclinuxu]

Tady se všecko vždycky přirovnává k autům... By mě zajímalo k čemu přírovnávaj na auto webech/fórech...

[pavlix]

Nejspíš k ženským :).

[xkucf03]

Přesně. Mercurial = blondýna, Git = bruneta. A teď si vyber

(to k tomu, jak ses mě ptal na to srovnání)

[pavlix]

Přesně. Mercurial = blondýna, Git = bruneta. A teď si vyber

Když mě se líbí všechny :) (teda jako ne všechny kusy, ale všechny barvy vlasů).

Tak od toho srovnání očekávám maličko víc, ale to je ti asi jasný :).

[poiuyt]

Pokud bych měl zahodit osvědčenou věc jako je git, která se IMO dá používat jak jednoduše, tak i složitě, tak k tomu musí být pádný důvod, ne plané řeči.

Hele, pavlixi, kdybys tady celou dobu nenadával na osvědčený SVN a nesnažil se prosazovat "jediný správný" Git, tak bychom ti možná věřili, ale takhle je to jen sračka...

...nojo, holt děláš pro ten Git školení, tak to musí být jediná správná cesta(tm), zpátky ni krok, že?

[pavlix]

Hele, pavlixi, kdybys tady celou dobu nenadával na osvědčený SVN a nesnažil se prosazovat "jediný správný" Git, tak bychom ti možná věřili, ale takhle je to jen sračka...

Milý anonyme, zřejmě jsi natolik dobrý ve čtení mezi řádky, že čteš i věci, které tam nejsou.

...nojo, holt děláš pro ten Git školení, tak to musí být jediná správná cesta(tm),

Obviňovat zrovna mě z „jediné správné“ cesty působí docela hloupě, ale jako anonym nic neriskuješ, že :). Původně jsem ti nechtěl ani odpovídat, ale nakonec mě napadlo, že by reakce mohla být zajímavá pro ostatní.

zpátky ni krok, že?

Tedy i pro ostatní...

Jako že bych se vrátil k Subversion, které jsem sám před časem několikrát prosadil jako první řešení i jako náhradu CVS? Řešení které jsem několikrát nasazoval a používal i pro vlastní projekty?

Ano, to zní celkem rozumně... kdybych se od začátku nesetkával s neschopností plně centralizovaného řešení, které potřebuje server i na vytvoření commitu, i třeba na přestavbu adresářové struktury!

Subversion v určitých situacích vykazuje omezení i oproti prostému zálohování adresářové struktury a sdílení patchů (dvě hlavní funkce verzovacího systému).

Nehledě na to, že nepodporuje větve a tagy (omezeným workaroundem je checkout a kopírování adresářů), a že práce se vzdálenými repozitáři je v Subversion velice komplikovaná oproti třeba zmíněnému Gitu.

Takže, opravdu nemám důvod se k Subversion vracet a už vůbec ne to komukoli doporučovat. Mně zajímají nástroje, které svým uživatelům nekladou zbytečné překážky, ale naopak jim pomůžou některé problémy překonávat.

Proto mě velice zajímá, co nabízí Mercurial a jiné z mého pohledu plnohodnotné systémy správy verzí, třeba oproti Gitu, což je jediný decentralizovaný VCS, který mám opravdu v ruce. Nevím s čím jiným bych měl srovnávat než s tím, co dobře znám.

Kecy o jediném správném řešení přenechám jiným, omezenějším, to není moje parketa :).

[Marián Kyral]

Tak jsem si zvykl na git a osobně jej dost používám. I když jen základy, žádné divočiny. Bohužel na hg přešel jeden projekt, který občas překládám. Hg a git mají celkem dost stejných příkazů, ale v jistých podstatných věcech se liší. Dodnes si třeba nepamatuji, jak je vrácení změn v konkrétním souboru - ekvivalent ke git checkout <file> . Vždy musím googlit.

[msk]

Dodnes si třeba nepamatuji, jak je vrácení změn v konkrétním souboru - ekvivalent ke git checkout <file> . Vždy musím googlit.

Kupodivu hg revert <file>

[Marián Kyral]

Bohužel v Gitu je revert jen a pouze k vrácení commitu. Proto si to nikdy nepamatuji.

[stativ]

Bohužel na hg přešel jeden projekt, který občas překládám.

Rawtherapee? Tam jsem se o mercurial z části přičinil i já

[Marián Kyral]

Bohužel na hg přešel jeden projekt, který občas překládám.

Rawtherapee? Tam jsem se o mercurial z části přičinil i já

I ty jeden

Všude jinde (kde mně to zajímá) používají buď Git, nebo ještě svn. Git mám super integraci se svn. Bohužel s Hg už to tak super není i když to nějak jde.

Trochu mně mrzí, že se mi nepodařilo dokončit přechod RT na gettext. Začal jsem na tom těsně po otevření kódu, dostal jsem to skoro až do finiše, lokalizovaná verze padala po kliknutí na některé checkboxy a nebyl jsem schopen zjistit proč. Pak se spustila doslova smršť změn, přešlo se na HG. Chvíli jsem se snažil udržet se změnami tempo a vedl jsem vývoj v Gitu, chtěl jsem to dotáhnout do nějaké použitelné verze. Pak ale nebyl čas, vývoj mi utekl a v současné době bych musel začít zase od začátku a na to už nějak není čas

Ale třeba někdy. Možná po přečtení tohohle seriálu. Ještě bych potřeboval trochu osvětlit, jak je to s větvemi. V Gitu jsou jednoduché a ve spojitosti s rebase je jednoduché udržet patch aktuální oproti aktuální větvi. Nevím jak je to v HG.

Mimochodem, myslíš, že je šance přejít v RT na gettext? Současný systém překládání má jisté mouchy - o aktualizaci anglického řetězce se překladatel doví jen a pouze ze seznamu změn na google code. Taky se špatně dělá revize překladu - v souboru chybí anglický rětezec na kontrolu.

Bohužel momentálně všechno padá na nedostatku času, případně naprosté nechuti cokoli po večerech dělat. Stačí mi to v práci

[kverulant]

Pro příklad můžu uvést moje argumenty proč používám právě mercurial a ne git. Mercurial je podstatně jednodušší na používáni, je lépe integrovaný v programech které používám (částečně historický důvod), je multiplatformní (historický důvod). Možná že dneska nebo za rok už to je jinak, ale já rozhodně nebudu každý rok migrovat jinam, jenom kvůli tomu, že je to zrovna in.

[msk]

Suhlas, tiez sme v predoslej firme vyberali nastupcu svn, vyhral to mercurial. Oproti git-u mi prisiel jednoduchsi, kompaktnejsi, rychlejsie som sa s nim naucil a stale poskytoval dostatok prostriedkov ku roznorodym advanced taskom ( ktore by 90% seniorov v mojom terajsom time aj tak mentalne asi nepobralo ). Cim nechcem povedat, ze git je zly, ale podla mojho nazoru pri preladovani mentality timu na distribuovany system je to o dalsiu komplikaciu naviac.

[Rivon]

Mě taky Mercurial přijde jednodušší než Git. Když sem začal jeden projekt, tak jsem ho nechtěl dělat open-source, bohužel GitHub ani žádná podobná služba nenabízí free private repo pro Git. Tak jsem zkusil BitBucket s Hg a Mercurial se mi hrozně zalíbil. Teď už BitBucket začal nabízet i Git, ale já stejně používám Hg...

[vladaf]

Free hostingy s private git repo rozhodně jsou. Jáý používám například ProjectLocker.

[Michal Vyskočil]

Mercurial je podstatně jednodušší na používáni.

Dokud jsem nečetl dokumentaci ohledně větví (jmenovitě LocalBranchExtension, NamedBranches, PruningDeadBranches BookmarksExtension a mercurial bookmarks), myslel jsem si to samé. Poté jsem bylo docela rád za hg-fast-export .

[pavlix]

Mercurial je podstatně jednodušší na používáni

Slyšel jsem o tom, i když je pravda, že si o moc jednodušší ovládání základních věcí gitu neumím představit. A pokročilé věci přece začátečníkovi nemůžou překážet, když je nechce používat.

je lépe integrovaný v programech které používám (částečně historický důvod)

Jakých? Netvrdím, že ne, ale zatím o žádném nevím.

je multiplatformní (historický důvod)

To je snad každý software této kategorie, který má mít aspoň trochu šanci.

Možná že dneska nebo za rok už to je jinak, ale já rozhodně nebudu každý rok migrovat jinam, jenom kvůli tomu, že je to zrovna in.

Což ale nebude fungovat na spolupracovníky jako důvod proto, aby migrovali oni třeba z Gitu.

[msk]

Ma dneska vyznam pouzivat nieco ine ako git ?

To sa pytam dnes a denne pri praci s neuveritelnou megasrackou od IBM, ktorej meno sa mi len hnusi vyslovit...

V com je toto lepsie ako git ? Co som pocul tak to poizivaju jedine preto lebo toto ma krajsie gui pre widly ako git.

Tak si pocul zle. GUI sice nepouzivam ( nie som uchyl ), ale existuje TortoiseGit a TortoiseHg, ktore pre 98% klikacich vyvojarov asi budu poskytovat identicku funkcionalitu.

Inak dovody preco hg su diskutovane nizsie.

[Milan]

Clearcase?

[msk]

J

[xkucf03]

To je myslím ještě ta lepší varianta – pak mají také Continuus/Synergy a to je teprve zážitek

[stativ]

V com je toto lepsie ako git?

V čem je git lepší než mercurial?

[kaja gottzilla]

Git ma ovela vyssi vykon.

Na aplikacii typu hello world alebo podobnej to nie je poznat. Ale projekty typu kernel, openembedded kde su miliony suborov tak tam je uz znacny rozdiel...

[msk]

Citation needed.

[stativ]

Git ma ovela vyssi vykon.

To je hodně odvážné tvrzení. Z vlastní zkušenosti rozdíl postřehnout nelze. Když mi merge bude trvat 1 s u gitu a 1.5 s u mercurialu tak mě to vážně netrápí a za značný rozdíl to nepovažuji. Ostatně

Naopak vidím pár důvodů proč mercurial ano a git ne. Mercurial má jednodušší rozhraní, takže se na něj snáze přechází, hlavně z VCS typu SVN a CVS. U gitu hodně bobtná repozitář, zapnutí garbage collection ale vše znatelně zpomalí. Mercurial má lepší podporu pro velké binární soubory.

[nou]

ale povedal by som ze pravdive. http://whygitisbetterthanx.com/#git-is-fast na druhu stranu su to prakticky rozdiely desatina sekundy vs pol sekundy.

[stativ]

Vždyť já jsem ani neříkal, že by git neměl větší výkon. On ho i většinou má (pokud se u gitu zrovna nepouští garbage collection), ale rozhodně to nepovažuji za o mnoho větší výkon. Navíc rychlost je u mercurialu pořád stejná, ale u gitu kolísá (viz třeba hg vs. git for server applications - performance test)

[pavlix]

Mercurial má jednodušší rozhraní, takže se na něj snáze přechází, hlavně z VCS typu SVN a CVS.

A existuje i nějaký důvod pro člověka, který považuje přechod ke Gitu za přirozený a přímočarý?

Mercurial má lepší podporu pro velké binární soubory.

A to jako v čem? :)

[jos]

tak třeba když jsme my vybírali nástupce svn, tak git ještě moc dobře nefungoval na widlích (jestli aspoň experimentálně)

stejně tak před delším časem se mohl někdo zeptat: mysql nebo postgres? musíme bejt na widlích takže mysql

na rozdíl od databáze není ale v našem případě volby mercurialu čeho litovat

[pavlix]

na rozdíl od databáze není ale v našem případě volby mercurialu čeho litovat

Nemůžu posoudit, znám dobře pouze Git. Ale když slyším o výhodách a v čem je něco lepší, jsem zvědavý na konkrétní údaje.

[Michal Vyskočil]

Abych zůstal u oblíbené analogie s auty - řekl bych, že srovnání git versus mercurial dopadne jako srovnání Audi Q5 versus BMW X5.

[pavlix]

Ani jedno z nich nevím, jak vypadá, natož v jakých se prodává barvách :).

[xkucf03]

Tak obecněji: jeden si např. oblíbil Volvo a druhý BMW. Myslím, že tady je jakýkoli flame zbytečný

[kralyk z abclinuxu]

Přesně. Git vs Mercurial je prostě otázka osobní preference.

[me]

O osobnich preferencich je to jen v pripade, ze verzovaci system pouzivate jen a pouze pro osobni potrebu a svuj kod nesdilite, pripadne jste sefem projektu a urcujete pravidla. Pokud pracujete na projektu s dalsimi lidmi, musite se prizpusobit; pokud prispivate do kernelu, budete nuceni pouzivat git. A pokud obcasne prispivate do nekolika projektu, musite se naucit pouzivat vsechny verzovaci systemy (git, mercurial, bzr, csv, svn...)

[kralyk z abclinuxu]

cpt Obvious to the rescue...

[Michal Vyskočil]

Tak obecněji: jeden si např. oblíbil Volvo a druhý BMW. Myslím, že tady je jakýkoli flame zbytečný

Tak moment, já o čínských autech nic nepsal .

[xkucf03]

Pro někoho možná překvapivě, zatím to vypadá, že čínský vlastník si počíná lépe než předchozí americký.

[msk]

Nieco mi uniklo ( okrem mocu )? A fakt !

[Michal Vyskočil]

Dobře, ale já nepsal nic ani o amerických autech

[jos]

já znam zase jen mercurial, ale pro mojí (naší) práci stačí luxusně; je mi jasný že s gitem bychom si nepohoršili

mezi mysql a postgresem sou dneska propastný rozdíly, kvůli kterým si lidi co před lety vybrali mysql trhají vlasy, jak byli krátkozraký

[pavlix]

Ale ty propastné rozdíly už jsou tam minimálně roky. Nejsem nějaký znalec databází, z mého pohledu je to odjakživa.

[Michal Kubeček]

Spíš se dá říct, že jsou dnes o něco menší než dřív…

[pavlix]

S tím by se dalo souhlasit.

[Michal Kubeček]

stejně tak před delším časem se mohl někdo zeptat: mysql nebo postgres? musíme bejt na widlích takže mysql

To je ale problém dotyčného, že si z nedostatku informací výběr zúží na jen na dvě databáze. :-)

[stativ]

A existuje i nějaký důvod pro člověka, který považuje přechod ke Gitu za přirozený a přímočarý?

Třeba ty další dva. Každopádně nevěřím tomu, že by někomu, kdo přechází ze SVN nebo CVS, přišel přechod ke Gitu přirozenější a přímočařejší než k Mercurialu. I kdyby jen proto, že Mercurial používá v mnoha případech stejné názvy příkazů jako svn.

A pokud ti přijde přechod ke Gitu přirozený, nevidím důvod, proč by ti měl přechod k Mercurialu přijít méně přirozený. V tom případě to bude plichta.

A to jako v čem? :)

To jako v tom, že ukládá celé soubory a zvlášť trackuje jejich hashe. Navíc Mercurial umožňuje při klonování repozitáře s binárními soubory stahovat pouze zadanou verzi binárních souborů (vlastně se tedy chová jako centralizovaný server), což je pěkné hlavně když ony binární soubory mají třeba několik set MB. Samozřejmě historie je kompletní, navíc ti nic nebrání v tom mít všechny uložené lokálně.

V době, kdy jsem pracoval s Gitem, Git řešil binární soubory stejně jako textové, takže overhead byl hodně velký. Rychlé hledání mi nepomohlo najít nic, co by naznačovalo tomu, že se to nějak výrazně změnilo.

[Michal Vyskočil]

wiki mercurialu se zmiňuje pouze o rozšířeních - tohle je něco jiného?

[stativ]

Jo, měl jsem na mysli LargeFiles extension. Je to oficiální rozšíření, které je bundlované přímo s mercurialem (2.0 a vyšším).

[pavlix]

Samozřejmě historie je kompletní, navíc ti nic nebrání v tom mít všechny uložené lokálně.

Takže něco jako git clone --depth 1, akorát s tím, že hranice toho, co se stahuje a co ne, souvisí vedle poloze na grafu i se signaturou daného objektu?

Vázat to na složení souboru mi přijde zbytečnost, ale pokud by šlo o velikost, byla by to první zajímavá informace, kterou bych se o Hg v této diskuzi dozvěděl. A taky první věc, která představuje alespoň jednu jasnou výhodu (i když bych ji osobně nevyužil).

Ale zatím se tu dozvídám cosi o rozlišování binárních a textových souborů, což mi pro účely ukládání přijde úplně k ničemu. Ani unixové systémy nerozlišují binární a textové soubory.

V době, kdy jsem pracoval s Gitem, Git řešil binární soubory stejně jako textové, takže overhead byl hodně velký. Rychlé hledání mi nepomohlo najít nic, co by naznačovalo tomu, že se to nějak výrazně změnilo.

Nevidím jediný důvod, proč by měl Git pracovat s binárními soubory jinak, a nevidím v tom ani žádný overhead.

Pravda, statisticky bývají velké soubory mezi binárními, ale rozpoznávat velikost souborů podle toho, jestli jsou binární mi přijde jako drbání levou nohou za pravým uchem.

[stativ]

Takže něco jako git clone --depth 1, akorát s tím, že hranice toho, co se stahuje a co ne, souvisí vedle poloze na grafu i se signaturou daného objektu?

Dalo by se to tak říct, akorát se nepoužívá nějaká signatura objektu, kterou si mercurial vycucá z prstu, ale to, co mu uživatel řekne. Když přidáváš soubor, můžeš explicitně říct, že ho má zpracovávat jako largefile. V nastaveních repozitáře je pak nastavení velikosti, při jejímž překročení jsou nově přidané soubory přednastavané jako largefile. Taky se dá nastavit maska jmen, které se mají automaticky považovat za large files (typicky něco jako *.jpg data/*).

[pavlix]

Tak to zní pro správu velkých souborů (kterou nedělám), relativně užitečně.

[aceman]

Mercurial pouziva napriklad aj Mozilla (Firefox/Thunderbird). Radovo 150 000 suborov, 2GB. Rozdiely (diff) 'working directory' oproti repozitaru urobi tak za 1s, pokial su metadata suborov v cache. Zda sa to byt dost rychle.

[Bystroushaak]

GIT má opensource knihu v češtině.

[GandY]

Kedže pracujem aj s HP-UX-om a AIX-om v rôznych verziách, mám vo zvyku si pripájať adresáre z týchto serverov cez sshfs. S git-om som mal pri tom problém s mercurial-om nie.

[Luboš Doležel (Doli)]

To bych nebral ani za vyloženou chybu gitu. Evidentně sshfs něco neumí.

[GandY]

Ja netvrdím, že je to chyba git-u (nič proti nemu nemám a pôvodne som naň chcel prejsť). Len reagujem na otázku či je dôvod používať mercurial namiesto git-u.

[pavlix]

Důvod typu „někdy kdysi mi něco nešlo a vůbec netuším, proč“ najdeš u jakéhokoli software X ve srovnání se software Y. A následně najdeš člověka, který to samé určitě někdy kdysi objevil v Y versus X.

[kralyk z abclinuxu]

Co som pocul tak to poizivaju jedine preto lebo toto ma krajsie gui pre widly ako git.

A MacOSX, afaik...

[Zadejte prosím své jméno.]

Díky za pěkný úvod, je to hezky shrnuté na jednom místě.

[Gilhad]

jmeno toho konfiguraku jsem cetl jako hhhh...grc :)

[finn]

Samotný soubor .hgignore je rovněž verzovaný – to je dobré jednak proto, že seznam se může v čase měnit (např. soubory, které jsme chtěli ignorovat v prvních verzích teď chceme verzovat a naopak), a jednak proto, že tento seznam se bude šířit společně s ostatními soubory – když uděláme push nebo pull, seznam ignorovaných souborů bude všude stejný.

Soubor .hgignore – aspoň já si to myslím – naopak není dobré vkládat do repozitáře, protože různí lidé mohou chtít ignorovat různé soubory.

[Ladicek]

Většina projektů má nějakou sadu souborů/adresářů, které je potřeba ignorovat vždycky, typicky výstupy nějakého build systému, soubory obvyklých vývojových prostředí apod. To se cpe do .gitignore. To, co si chtějí různí lidé ignorovat navíc a nehodí se do "globálního" nastavení, to se narve do .git/info/exclude. Neznám Mercurial, ale předpokládám, že nějaká obdoba tam bude.

[stativ]

V konfiguraci repozitare si muzes rict, odkud se maji filtry brat. Bezne se pouziva postup, kdy clovek ma jeden globalni .hgignore soubor, ktery je nastaveny v ~/.hgrc a pak se v kazdem repozitari pouziva lokalni .hgignore.

[Filip Jirsák]

různí lidé mohou chtít ignorovat různé soubory

Chtít mohou, ale to je asi tak všechno. Když si nastavím, že soubory .bž chci já ignorovat a někdo jiný je ignorovat nebude, dotyčný je commitne do úložiště a já je s příštím updatem odsud dostanu. Výsledkem bude, že změny v úložišti se budou propagovat ke mně, ale opačně ne, takže jen budu neustále řešit konflikty.

[Martin Mareš]

Tohle alespoň v Gitu nenastane, protože Git nikdy neignoruje soubory, které už jsou součástí repository.

[xkucf03]

Mercurial to má stejně – a právě kvůli tomu ty problémy můžou nastat*. Ten .bž soubor může být třeba .class soubor. Já budu společný .hgignore uznávat ale někdo jiný** ne, nebo tam ty .class soubory přidá ručně… Tak to bude přesně jak píše Filip – při příští aktualizaci si je stáhnu, při kompilaci je změním a při hg commit mi je to bude nabízet k postoupení do úložiště.

*) když se v týmu objeví anarchista, který ignoruje společný .hgignore.

**) protože si myslí, že je nejchytřejší a že verzovací systém mu nemá co kecat do jeho práce.

[kralyk z abclinuxu]

Takže stručně řečeno problém je, že někdo může do repo přidat soubory, které tam nepatří? To mi nepřijde jako velký objev, navíc s .[git|hg]ignore to v zásadě nesouvisí...

[pavlix]

S tím tak úplně nesouhlasím.

[Gilhad]

git to ma udelane tak, ze .gitignore verzovat muzes, ale nemusis. Takze si kazdy muze vybrat podle svych potreb. Nemam rad, kdyz nekdo vi lip nez ja, co vlastne potrebuju a proto mi to nasilim vnucuje ... vetsinou se totiz myli

[Filip Jirsák]

To, zda má být nějaký soubor ve sdíleném úložišti nebo ne, je podle mne vlastnost toho souboru. Stejně se nemůžete rozhodnout jenom sám – když budete chtít nějaký soubor vynechat ze sdíleného úložiště, ale někdo jiný ho tam commitne, stejně tím vaše rozhodnutí přebije.

[xkucf03]

Vždyť je to taky jen na tobě, zda uděláš hg add .hgignore nebo ne. Akorát já bych doporučoval to udělat, protože si myslím, že každý projekt by měl mít nějaká společná pravidla, kterými se všichni řídí – ať už je to způsob odsazování, konvence pojmenování metod, nebo třeba rozhodnutí, které soubory se verzují a které ne.

[Gilhad]

aha, z clanku jsme mel dojem, ze .hgignore je verzovan automaticky. Ale s HG nedelam, takze vlastni zkusenost nemam.

[pavlix]

git to ma udelane tak, ze .gitignore verzovat muzes, ale nemusis.

O tom řeč není, je to stejné v Gitu i v Hg.

Takze si kazdy muze vybrat podle svych potreb.

Ale každý projekt, ne každý jednotlivec, a to jak v Gitu, tak v Hg.

Nemam rad, kdyz nekdo vi lip nez ja, co vlastne potrebuju a proto mi to nasilim vnucuje ... vetsinou se totiz myli

V některých projektech se i spolupracuje. Proto se do správy verzí dávají. Hele já netuším, co dáváš do .gitignore ty, ale já tam dávám například výsledky kompilace a neverzované konfigurační soubory.

A zatím jsem ani jednou nenarazil na situaci, kdy by bylo užitečné něco u jednoho uživatele v .gitignore mít a u druhého ne. To, jestli je soubor určený pro zařazení do repozitáře stejně nejde rozhodnout u různých uživatelů různě, když větve daného repozitáře sdílejí mezi sebou.

A pokud by je z nějakého důvodu nesdíleli, tak problém ani neexistuje.

[Gilhad]

Ja tam davam soubory, co mi v pocitaci z nejruznejsich duvodu vzniknou a nechci je automaticky zahrnout do projektu.

Protoze i v ramci jednoho projektu muzou pracovat ruzni lide s ruznymi funkcemi, muzou byt i ty pozadavky ruzne. Ja kdyz vetsinou pisu kod a nepisu dokumentaci, tak si casto delam poznamky, co chci dal udelat, do souboru jako todo.txt, uvahy.txt a pro debugovani presmerovavam vystup do souboru jako zxcvxcz.txt - proto mam v .gitignore *.txt. Kolega, ktery ma dokumentaci na starost naopak *.txt v .gitignore nema, protoze v podstate nedela nic jineho. vysledek je ten, ze ja mam na lokale kompletni dokumentaci a on tam nema muj docasny bordel. Kdybych nahodou spachal dokumentaci, tak ji muzu pridat rucne a to pravidlo tim prebit.

Jak je videt, existuji i scenare, kdy lze u ruznych uzivatelu rozhodovat ruzne, jake soubory (jimi vytvorene) automaticky zahrnovat a jake nikoli.

[Filip Jirsák]

Vy jste ale nepopsal různé přístupy pro různé uživatele, ale opět různé přístupy pro různé soubory. Akorát ta pravidla musíte nadefinovat trochu pečlivěji, než všechny soubory s příponou txt. Ale to je rozumné udělat stejně, protože to budete stejně potřebovat pro udržení nějakého pořádku v projektu, pro sestavovací skripty atd.

[Gilhad]

Az na to, ze pokud ja udelam kdekoliv soubor README.txt, tak ten soubor neni a nema byt soucasti distribuce. Zatimco pokud on udela kdekoli (treba na stejnem miste) soubor README.txt (a klidne i s tim samym obsahem), tak ten soubor je a ma byt soucasti distribuce. To mi vazne prijde spis jako rozdil mezi uzivateli, nez mezi soubory.

Definovat pravidla jinak neni treba, protoze delaji presne to co maji - jeho *.txt jsou zahrnuty automaticky, moje *.txt jsou automaticky ignorovany. Tezko na tom neco definovat pecliveji.

Sestavovaci skripty si vytahnou kopii primo z gitu, cili maji presne to co mit maji, takze taky nevidim zadny problem s nima - nejsem takovy sebevrah, aby skripty jely z neceho, co muze, ale nemusi byt verzovane a muze obsahovat libovolne plevelne soubory.

[Filip Jirsák]

Pokud vy vytvoříte svůj dočasný soubor README.txt na místě, kde může být trvalý verzovaný README.txt, je to prostě váš nepořádek, a žádný verzovací systém to nezachrání. Až někdo ten soubor v úložišti vytvoří a vy si uděláte update, o ten svůj obsah přijdete – takže asi není vůbec důležitý, tak ten soubor ani nevytvářejte, a máte vystaráno. To, že verzovací systém vás nepodporuje ve vaší snaze vytvářet ve sdíleném úložišti chaos, není jeho chyba, ale základní vlastnost, která tomu systému dává vůbec smysl.

[Gilhad]

gilhad: mam rad, kdyz ma kazdy uzivatel moznost rozhodnout se sam pavlix: To, jestli je soubor určený pro zařazení do repozitáře stejně nejde rozhodnout u různých uživatelů různě

gilhad: lze to rozhodnout ruzne, vim to, protoze to tak delame a funguje nam to dobre. Pro ruzne uzivatele mame ruzna pravidla.

Jirsak: Ne, vy nemate ruzna pravidla pro ruzne uzivatele, ale pro ruzne soubory, jen to musite sloziteji popsat, abych mel pravdu ja a ne vy

gilhad: Ta pravidla jsou pro ruzne uzivatele ruzna a podle toho, ktery uzivatel je aplikuje tak je s jinak stejnym souborem jinak nalozeno

Jirsak: To je jen vas neporadek a verzovaci system vas pred nim nezachrani, protoze vim lip nez vy co potrebujete, tak to koukejte okamzite delat po mem. To co vam vyhovuje se mi nelibi a tak to nedelejte.

gilhad: nechci, aby mi verzovaci system branil udelat to, co mi vyhovuje delat. Takze mi vyhovuje, jak se ten system da nastavit. Jirsak me neplati, takze si to budu delat jak to vyhovuje me, nikoli jak si to predstavuje on od sveho stolu. Jirsak si muze nastavit system jak chce, ale ja si ho nastavim tak jak chci ja.

[Filip Jirsák]

Současné běžně používané souborové systémy i systému pro správu verzí používají cestu a název souboru jako jednoznačný identifikátor. Nemůžete mít tedy dva různé soubory se stejným názvem. To, o co se pokoušíte – mít pod jedním názvem jeden soubor verzovaný, a zároveň jiný soubor neverzovaný – je tedy na běžně používaných systémech nesmysl a nebude vám to fungovat. Nikdo vám samozřejmě nebrání pokoušet se o to, ale když to nejde, nesvádějte to na chybu toho systému – vlastnost 1 název = 1 soubor je u těch systémů jasně deklarovaná a je vaše chyba, že ji ignorujete.

[Gilhad]

Samozrejme nam to funguje - verzovaci system neprepise soubor bez varovani, takze ja o sve soubory neprijdu. Moje soubory jsou znacne docasne, kolegovy jsou trvale - pokud se strefime s umistenim a nazvem, ja si poresim sve veci, uklidim po sobe a pak teprve akceptuju kolegovy zmeny. Vetsinou se ovsem takto nepotkame, protoze ja ty soubory vytvarim (a zase rusim) v jinou dobu nez on - je je delavam hlavne v pocatku vyvoje dane oblasti, on vetsinou az po ukonceni vyvoje.

Ovsem princip, ze dva uzivatele muzou v ruznou dobu udelat soubor se stejnym nazvem a s timto souborem bude nakladano podle toho, KDO jej vytvoril, nikoli pouze KDE je a jak se jmenuje zustava.

Ja to nepovazuju za chybu systemu, ale prave naopak za vyhodu, ze mi umozni mit jina pravidla pro zahrnovani souboru do verzovani nez jaka ma kolega, jehoz prace je jina a tudiz ma jine naroky.

Pokud bychom se ridili vasimi pravidly, museli bychom kazdou chvili prepisovat pravidla, abychom se dostali k chovani, ktere by nam aspon trochu vyhovovalo. Ale samozrejme kazda nutnost rucni zmeny neceho vnasi prostor pro chyby a snizuje uzivatelsky komfort. Cili prejit na vase pravidla by pro nas znamenalo pouze vice problemu a vice prace, aniz by to prineslo nejakou vyhodu.

Ostatne cela diskuze neni o tom, jakym zpusobem bychom si my meli zorganizovat praci (aby byl Jirsak s nami spokojen], ale zda je mozne, aby byli uzivatele, kteri vyuzijou ke sve spokojenosti danou vlastnost systemu (ackoli Jirsak zrovna tuhle vlastnost nepouziva). Bylo dokazano, ze takovi uzivatele existuji.

[Filip Jirsák]

Já jsem nikdy netvrdil, že mít chaos v souborech není možné. Je to možné, jenom je to nepraktické. A vy tu nepraktičnost jen názorně ilustrujete. Když se někdo podívá na váš projekt, nedokáže vůbec určit, které soubory jsou společné a mají být verzované, které jsou jen vaše pomocné atd. Dokážete to určit jenom vy, dokud si pamatujete, co který soubor znamená. Musí to být dobrodružné, když pak po nějaké době vzpomínáte, které soubory jste do VCS zapomněl dát, které jste tam naopak přidal omylem… Proto se obvykle v projekty rozdělují na různé podadresáře, v jednom jsou zdrojáky, v dalším dokumentace, v dalším sestavená aplikace, v jiném logy nebo dočasná výstupy. Pak každý ví, že naklonováním úložiště a přikopírováním svého adresáře s konfigurací dostane čistý projekt nakonfigurovaný podle svých potřeb, smazáním adresáře s logy a se sestavenou aplikací dostane opět čistý projekt atd. A nemusí si pamatovat, že tenhle README.txt je jen jeho a ve skutečnosti tam patří soubor, který vytvořil kolega, támhle má zašoupnutý důležitý konfigurační soubor svého IDE, který je potřeba si zálohovat…

[kralyk z abclinuxu]

Když se někdo podívá na váš projekt, nedokáže vůbec určit, které soubory jsou společné a mají být verzované, které jsou jen vaše pomocné atd.

Myslíš tím, že někdo nakoukne do jeho lokální pracovní kopie? A proč by to někdo dělal? Když se chce někdo "podívat na projekt", stáhne si přece to, co je v repo, ne? Tam jsou všechny soubory potřebné pro projekt.

A nemusí si pamatovat, že tenhle README.txt je jen jeho a ve skutečnosti tam patří soubor, který vytvořil kolega

Ale vždyť to si nemusí pamatovat. Ten "správný" README.txt, který má na daném místě být, je uložen ve VCS. A VCS nezapomíná, od toho to přece je VCS.

Přijde mi, že hledáš problémy tam, kde nejsou.

[Gilhad]

Kdyz se nekdo podiva na nas projekt, tak si ho stahne z gitu a uvidi jen to co tam patri. Co mam na lokalnim disku, do toho nikomu nic neni.

Jake soubory potrebuju dat do verzovaciho systemu je velice jednoduche - git add -A - a diky spravne nastevenym .gitignore se prida vse, co tam patri a neprida nic co tam nepatri - od toho to tam prece je, takze zadne slozite vzpominani nehrozi :)

Nejak mi prijde, ze fakt hledate problemy tam, kde zadne nejsou, jen abyste prosadil svuj pohled na to, jak mame my delat svoji praci.

[pavlix]

Ale ruku na srdce, opravdu denně ty a tví kolegové používáte git add -A? Kolik přidáváš denně nových souborů do repozitáře? A kolik v rámci jednoho commitu?

U mě je naprostá výjimka, když v rámci commitu přidám více než 2-3 soubory. Takže volbu pro přidání všech používám tak leda když zakládám úplně nový repozitář a zároveň nezakládám nový projekt. A to ještě většinou pečlivě kontroluju, co všechno se má opravdu v repozitáři objevit.

Jako dělejte si to jak chcete, ale přijde mi, že celý ten výstup s neverzováním .gitignore je založený na nějakém předchozím špatném rozhodnutí.

Ze stejného důvodu mnozí nemůžou přejít na Git od Subversion. Mají zavedené nějaké špatně zvolené procesy, které nechtějí měnit.

[xkucf03]

Ze stejného důvodu mnozí nemůžou přejít na Git od Subversion. Mají zavedené nějaké špatně zvolené procesy, které nechtějí měnit.

Jaké třeba? Docela by mě to zajímalo. Z těch věcných mě napadá snad leda zamykání* (které v SVN jde krásně, zatímco v distribuovaných systémech z principu nejde), ale jinak to jsou všechno jen technologické problémy a nekompatibility (např. máme podporu v IDE pro systém X ale ne pro Y, nebo: napsali jsme si pro to spoustu skriptů a nechce** se nám je předělávat), ale na ty člověk narazí při přechodu z jakéhokoli systému na jakýkoli.

Jinak bych řekl, že přejít na Mercurial (Git to podobně) a používat ho stejným stylem jako SVN jde bez problémů – bude se používat jako centralizovaný systém (v podstatě stačí si spojit commit+push a update+pull) a ta distribuovanost nového systému zůstane akorát nevyužita.

*) to navíc není z principu špatné – je to jen jiný (a někdy lepší) způsob práce

**) mimochodem tohle je zcela legitimní důvod – když přechod bude znamenat víc práce než užitku, tak prostě přecházet nebudu, i kdyby ten nový systém byl sebekrásnější

[pavlix]

Třeba možnost řízení přístupu na úrovni jednotlivých adresářů a souborů uvnitř jedné větve. Potom lineární číslování commitů. Teď nic víc z paty nevytáhnu.

[xkucf03]

Třeba možnost řízení přístupu na úrovni jednotlivých adresářů a souborů uvnitř jedné větve.

hmm a chtít tohle je „špatně zvolený proces“?

[pavlix]

Podle mě ano. Projekt lze rozdělit na podprojekty a utvářet přístup na základě podprojektů... ale to je jen osobní názor, teď k faktům.

Vzhledem k Gitu a obecně DVCS je to opravdu špatně zvolený proces. Ony se ty procesy pak musí volit i vzhledem ke zvolenému způsobu verzování a princip DVCS přináší i určitá omezení, to je potřeba si přiznat. Ta omezení se dají do určité míry obcházet, ale nikdy to není ideální.

[xkucf03]

Podle mě ano. Projekt lze rozdělit na podprojekty a utvářet přístup na základě podprojektů...

To si právě nemyslím. Dejme tomu, že máš nějaký větší projekt a chceš omezit právo zápisu do jednotlivých částí. Testeři můžou psát testy (→ zapisovat do /testy), ale jinak nikam. Programátoři můžou zapisovat do implementace a do testů. Analytici a dokumentarista můžou zapisovat do /analýza resp. /dokumentace. A číst můžou všichni všechno.

Samozřejmě se to jde řešit i ex-post – když zjistíš, že někdo zapisoval někam, kam neměl, tak mu dojdeš vynadat. Většinou v tom nebude zlý úmysl, ale prostě jen někdo přepsal omylem jiné soubory… A když jde takovým chybám zabránit dobrým nastavením práv, tak je to lepší (než ručně všechno kontrolovat).

A když to uděláš jako víc úložišť, tak se ti to velice snadno rozjede a za chvíli nebudeš vědět, které testy pasují ke které verzi implementace… Nemluvě o větvích a štítkách, které je potřeba udržovat napříč několika úložišti.

Vzhledem k Gitu a obecně DVCS je to opravdu špatně zvolený proces.

Proces je podle mého primární – a VCS je jen nástroj, který ho má podporovat. Takže jestli to Git neumí, tak je to spíš špatná volba nástroje.

princip DVCS přináší i určitá omezení, to je potřeba si přiznat.

Pokud jde o řízení přístupu pro čtení, tak souhlas, to je více méně nemožné (nebo minimálně hodně pracné a neefektivní). Ale řídit práva k zápisu v principu není problém (ostatně některé distribuované systémy to podporují).

[pavlix]

omezit právo zápisu

To si ale špatně rozumíme. Omezit právo zápisu není v Gitu až takový problém, stačí kontrolovat commity před přijetím. Pokud to nechceš dělat na lidské úrovni, umí to tuším Gitolite.

Takže zde nejsme ve při :).

Proces je podle mého primární – a VCS je jen nástroj, který ho má podporovat. Takže jestli to Git neumí, tak je to spíš špatná volba nástroje.

Procesy se mezi VCS a DVCS můžou výrazně lišit. A mírně se můžou lišit i mezi jednotlivými DVCS. Můžeš být idealista, ale občas je vhodnější se přizpůsobit, než psát si vlastní DVCS, protože ti ostatní nevyhovují. Občas ne – tak přece vznikl Git.

Pokud jde o řízení přístupu pro čtení, tak souhlas, to je více méně nemožné (nebo minimálně hodně pracné a neefektivní).

Já ale psal přístup, čímž jsem měl samozřejmě na mysli obecný přístup. Nenapadlo mě, že si to hned přeložíš jako zápis. Ale ono je prakticky nemožné řídit i ten zápis, pokud za zápis považuješ commit do vlastního repozitáře.

Konceptuálně tak vlastně neřídíš zápis do adresářů, protože zápis do adresářů Git neumožňuje (je v něm vše neměnné, kromě seznamů referencí). Je možné pouze limitovat to, co odeslané commity můžou zahrnovat. Ale jde se na to samozřejmě dívat různě.

[Gilhad]

Ne, pouzivam git add -A pouze kdyz pridavam spoustu souboru naraz, coz je jednou za uhersky rok. Normalne pouzivam git commit -am "text", nove soubory do repozitare pridavam jen zridka.

Zato docasne textaky vytvarim co chvili (a zase mazu jakmile prestanou byt aktualni). Prave proto mi vyhovuje, ze u me se zadny txt neprida sam od sebe. Kolega zase naopak dela prakticky jen ty textaky, jestli a jak si dela nejake docasne poznamky nevim, ale spis asi ne.

Pro tento specificky pripad delby prace ty ruzne .gitignore jsou nejjednodussi reseni. Pro jine pripady spoluprace to samozrejme muze byt (a byva) jinak. Mam i par dalsich projektu, kde je .gitignore verzovany, protoze tam to naopak dava smysl (nebo je jedno kdyz na nich delam sam a pak je to stejne lepsi verzovat).

Takhle debata nevznikla o tom, zda je lepsi verzovat ci neverzovat .gitignore (obecne je lepsi verzovat), ale zda ma smysl tato moznost a zda ji vubec muze nekdo rozumne vyuzit (muze - ve znacne specifickych pripadech).

[pavlix]

Takhle debata nevznikla o tom, zda je lepsi verzovat ci neverzovat .gitignore (obecne je lepsi verzovat), ale zda ma smysl tato moznost a zda ji vubec muze nekdo rozumne vyuzit (muze - ve znacne specifickych pripadech).

Potom ale začátek této debaty vnímám přesně opačně než ty.

[xkucf03]

Moje soubory jsou znacne docasne, kolegovy jsou trvale

A nebylo by jednodušší si pro dočasné soubory dohodnout nějakou jinou příponu (třeba .poznámky místo .txt)?

Ale samozrejme kazda nutnost rucni zmeny neceho vnasi prostor pro chyby a snizuje uzivatelsky komfort.

Jak bez společného .*ignore souboru řešíš situaci, kdy se např. změní proces sestavování a začnou vznikat nové dočasné soubory, které není žádoucí verzovat?

Se společným ignorovacím souborem by jednoduše ten, kdo změnil proces, upravil i ignorovací seznam a všichni ostatní by si stáhli oboje najednou při příští aktualizaci. Tzn. nestane se mi, že bych si např. stáhl nový Makefile, ale zapomněl ručně upravit .*ignore soubor a přidat do něj další výjimky (Jak se o nich mám dozvědět? Pošle mi je někdo e-mailem? Nebo si je mám domyslet z toho, jaké nové dočasné soubory teď nově vznikají?).

[Gilhad]

Ja uz jsem zvykly na .txt pro textove soubory a kdyz to nedela zadne problemy, tak se mi nechce to menit.

Sestavovani je taky jednoduche, potrebne soubory si pridam do sveho .gitignore. Kolega pise dokumentaci, takze tohle nepotrebuje resit, na testovacim pocitaci to taky netreba resit, protoze se proste smaze cely strom a nahodi novy a sestavovani pro release to opet neresi, protoze to si taky smaze cely strom a vytvori novy, aby v releasu nebylo nic, co neni v gitu (coz plati stejne i pro testovani)

Pokud by se projektu ucastnilo vic programatoru, tak bychom to treba delali jinak, podle toho, co by pro nas bylo vyhodne. Protoze pravidla jdou nastavit pro kazdy projekt zvlast, tak to taky neni zadny problem.

Na gitu se mi velice libi, jak jde pouzit jak pro obludy typu kernel, tak i pro vrabce typu psani povidky jedinym clovekem a porad je snadne s nim pracovat a prizpusobit si workflow pozadovanemu rozsahu a situaci :)

[pavlix]

Tady se vším souhlasím.

[Ladicek]

A nebylo by jednodušší si pro dočasné soubory dohodnout nějakou jinou příponu (třeba .poznámky místo .txt)?

A nebylo by jednodušší, když už to Git umí, používat společný (a verzovaný) .gitignore a individuální (a z principu neverzovaný) .git/info/exclude (příp. ~/.gitconfig)? Já bych tyhle internety zakázala.

[pavlix]

Good point.

[xkucf03]

Bezpochyby ano. Ale psal jsi to tu už tři dny zpátky a navzdory tomu se tu stále vede tahle diskusi – tak jsem myslel, že hledáme ještě nějaké jiné řešení Proto jsem navrhoval třeba tu jinou příponu. Dalším možným řešením je tyhle dočasné soubory vůbec nevytvářet – většinou si tam stejně vývojář syslí nějaké informace, o které se nechce podělit s ostatníma – ať je laskavě hodí do wiki, na síťový disk nebo do úložiště. Protože pak to v některých týmech vypadá tak, že po odchodu jednoho člověka (který si s sebou vezme i tyhle soubory, které měl jen on) se práce na nějakou dobu zastaví – než někdo jiný znovu vynalezne kolo a objeví to, co bylo původně v těch neverzovaných souborech…

[pavlix]

většinou si tam stejně vývojář syslí nějaké informace, o které se nechce podělit s ostatníma – ať je laskavě hodí do wiki, na síťový disk nebo do úložiště

Nebo do samostatného na to určeného adresáře, jak jsem navrhoval já, pokud už trvá na tom, že to musí být uvnitř pracovního adresáře.

[pavlix]

Podle mě velmi jednoduchou věc řešíte zbytečně složitě, nic víc. Jirsák uvádí všechno ad absurdum, ale na to už si snad všichni zvykli.

[kralyk z abclinuxu]

Až někdo ten soubor v úložišti vytvoří a vy si uděláte update, o ten svůj obsah přijdete

Není pravda. Záleží samozřejmě, jakou metodou a v jaké situaci se ten update provede, ale afaik v žádném případě git jen tak nepřepíše změněné lokální soubory (bez --force). Zobrazí nějaké upozornění, kolega Gilhad si svůj obsah přesune někam pod nekonfliktní název, a všecko je ok.

[pavlix]

Pod nekonfliktním názvem to mohl mít dávno, třeba v adresáři local, který je ve společném .gitignore či .hgignore.

Souhlasím s tím, že je dobře, že jim Git i Hg umožňuje dělat tyhle prasárny, a stejnětak souhlasím s tím, že je špatně, že té možnosti opravdu využívají, když to vůbec není potřeba.

Ale konec konců je to jejich věc a nemám důvod argumentovat jirsákovinama typu že přijdou o data nebo tak něco. Na to si dotyčné VCS dávají docela pozor.

[pavlix]

Každopádně díky za úvod do Mercurialu... měl bych pro tebe malý kšeft, docela by se mi hodilo nějaké podrobnější srovnání s Gitem ve formě konzultace. Pokud si přitom utřídíš informace pro další články, tím líp pro tebe.

V diskuzi sice padlo pár náznaků, ale celkově to vypadá, že jsi tu jediný, kdo je schopný přijít s konkrétními informacemi. Pokud někomu křivdím, tak se omlouvám, ale jak už jsem psal výše, kecy nemaj cenu.