Komentáře k článku

Druhý důvod proč zvolit Git: Snadné vytváření a slučování větví

git logo

V minulém článku jsme ukázali, že Git je nástroj pro správu verzí, který je zároveň velmi jednoduchý i velmi flexibilní. Především nám však nevnucuje pečlivé plánování pracovních postupů a neříká „to jsi nejdřív měl…“ Dnes se podíváme na to, zdali to platí i při práci s větvemi (branch) a jejich slučováním (merge).

Zpět na článek

84 komentářů k článku Druhý důvod proč zvolit Git: Snadné vytváření a slučování větví:

  1. xurfa

    a bez toho „evangelizování“ by to nešlo?

    Už jenom z toho dementního postoje „jedině Git přinese všem spásu“ naskakuje normálním lidem husí kůže…

    1. Aleš Roubíček

      Re: a bez toho „evangelizování“ by to nešlo?

      Zbývá jen otázka, dokázal jses v životě pro něco nadchnou a své nadšení předávat dál ve víře, že to někomu pomůže?

      Pokud se ti nelíbí Karlův styl, tak ho prostě nečti. Nkdo tě do toho nenutí.

      1. xurfa

        Re: a bez toho „evangelizování“ by to nešlo?

        Aha, takže součástí toho, že se pro něco nadchnu je i kálení hnoje na ty druhé? Velmi dementní „logika“…

        (P.S. Kdyby ten článek byl napsak kapičku méně fanaticky, dal by se docela i čísti…)

        1. Michal

          Re: a bez toho „evangelizování“ by to nešlo?

          Moc peknej prispevek.

          Zlodej krici chytte zlodeje a to primo pri kradezi….

    2. Karel MinaříkAutor příspěvku

      Re: a bez toho „evangelizování“ by to nešlo?

      Ale to není ani o nadšení, ani o stylu.

      Tématem těchto článků je „Proč zvolit Git“, jak je uvedeno v jejich titulku.

      Takže se v nich nedočtete o tom, proč strávit Silvestra doma nebo proč naopak odjet na lyže do Alp, ale o důvodech, proč (případně) zvolit Git, nebo se na něj aspoň pořádně podívat.

      1. xurfa

        Re: a bez toho „evangelizování“ by to nešlo?

        V tom případě je takový článek naprosto k (sprominutím) hov­nu.

          1. xurfa

            Re: a bez toho „evangelizování“ by to nešlo?

            Nevím proč by moje komentáře měly cokoliv „zachraňovat“. Komentáře jsou (na většině slušných webů) korektivem proti tomu, když někdo píše cípoviny; takže jestli jsem se nasraně ohradil, tak plním přesně tuto funkci.

            1. Martin Malý

              Re: a bez toho „evangelizování“ by to nešlo?

              Na většině slušných webů je rovněž zvykem, že komentátor jasně formuluje své výhrady vůči textu. Tuto funkci neplníte. Plníte leda tak funkci vrhače „dementů“, „hoven“ a „nasranosti“. Abych parafrázoval váš titulek: a bez toho fekálního slovníku by to nešlo?

              1. Renda

                Re: a bez toho „evangelizování“ by to nešlo?

                No on ani ten fekální slovník (dost dobrý název) mu moc nejde. „Cípoviny“ ??? Když už chci takové slovo použít, musím ho umět napsat.

              2. xurfa

                Re: a bez toho „evangelizování“ by to nešlo?

                Neumíte číst, své výhrady jsem jasně napsal a totiž to, že mě (na jinak věcném článku) štve, že se v každé druhé větě musí navážet do „konkurence“…

                1. Martin Malý

                  Re: a bez toho „evangelizování“ by to nešlo?

                  Číst umím. Jestli nebude spíš problém, že jste to přes veškerou snahu napsal až teď.

            2. Michal

              Re: a bez toho „evangelizování“ by to nešlo?

              Chtel jste napsat „Diskuze na netu jsou V CECHACH korektivem …“

              Ano ano, vetsina lidi v Cechach opravdu nema nic dulezitejsiho na praci nez si lecit sve komplexy neustalymi negativy cehokoli, ono ostatne nejde jen o diskuze ze jo?

  2. lupen

    číslování revizí

    Co se mi na gitu nelíbí je číslování revizí. Na SVN je to krásná lineární řada 1, 2, 3, … Ale ty hashe v gitu jsou takové ošklivé. Je možné to nějak přepnout?

    1. abtris

      Re: číslování revizí

      Prepnout zrovna ne, ale da se napriklad post-commitem, revize spocitat:

      git rev-list –all | wc -l | sed „s/[ t]//g“

      ulozit nekam do souboru a pouzit napr pri deploymentu.

      Ve SVN to stejne delame podobne, pokud chci na serveru napr. zobrazovat cislo revize v aplikaci.

      1. Aleš Roubíček

        Re: číslování revizí

        Taky jsem ukazoval číslo revize SVN, abych věděl, co je venku, ale po přechodu na git to vypadalo hnusně. Nakonec tam mám číslo buildu. CI server po úspěšném buildu vytváří v gitu tag s tímto číslem.

    2. Karel MinaříkAutor příspěvku

      Re: číslování revizí

      > Na SVN je to krásná lineární řada 1, 2, 3, … Ale ty hashe v gitu jsou takové ošklivé.

      Jen doplním odpověď na dotaz – z definice to nejde: kvůli tomu, že Git je distribuovaný (viz další díl), nemá žádnou možnost konstruovat po sobě lineárně „krásně“ jdoucí čísla.

      V praxi se často používá zkrácený hash (prvních 6–8 znaků), nebo tagy, jak píší kolegové. A především si stejně většinou posíláte odkazy do nějakého webového rozhraní, a la http://github.com/…4bf9b4b998b9. Hash je prostě implementační detail, nikdo to neřeší :)

      1. Tom

        Re: číslování revizí

        HG to umí. Je tedy zcela možné mít i u distribuovaných verzovacích systémů. Tohle je nedostatek Gitu. Snad to jednou vyřeší. Je to taky jeden z mnoha důvodů proč jsem dal přednost HG před Gitem.

        1. David Majda

          Re: číslování revizí

          Upřesnil bych to: Mercurial používá k identifikaci changesetů také hashe, ale zároveň je aliasuje na lineární posloupnost čísel. Tato posloupnost může být ale jiná v každé kopii repository, čísla tedy jednoznačně identifikují pouze changesety v lokální kopii.

          V praxi to příliš nevadí, protože 90% věcí člověk stejně dělá lokálně. Musí se jen myslet na to, že kolegovi vedle už nesmím poslat číslo, ale hash.

          1. Karel MinaříkAutor příspěvku

            Re: číslování revizí

            > V praxi to příliš nevadí, protože 90% věcí člověk stejně dělá lokálně. Musí se jen myslet na to, že kolegovi vedle už nesmím poslat číslo, ale hash.

            Právě, právě. To by se mi nechtělo :)

            Můžu dotaz, k čemu jsou pak lineární čísla vlastně dobrá? Jako že pak při hg log vidím posloupnost a ne (zkrácené) hashe?

            1. David Majda

              Re: číslování revizí

              Já třeba docela často hledám konkrétní changeset přes hg log (popř. hg log -k). Vypadne na mě něco takového:

              changeset:   22:c170698a4a26
              tag:         tip
              user:        David Majda 
              date:        Sun Nov 01 21:01:04 2009 +0100
              summary:     .bashrc: Added workaround for https://bugs.launchpad.net/vim/+bug/402188.

              Když si pak chci zobrazit od toho changesetu diff, revertnout ho apod., tak nemusím z terminálu copy-pastovat hash (tj. sahat na myš, což je pro mě při práci v terminálu něco jako pro počítač page-fault), ale stačí použít -r 22, což napíšu v pohodě ručně.

              Několikrát jsem už taky v historii doloval něco složitějšího a potřeboval jsem si přitom poznamenat několik konkrétních changesetů, abych s nimi později něco udělal. Opět je to pohodlnější pomocí čísel (můžu poznamenat třeba na papír).

              Obyčejná čísla jsou proti hashům zkrátka na práci příjemnější.

              1. Karel MinaříkAutor příspěvku

                Re: číslování revizí

                > Obyčejná čísla jsou proti hashům zkrátka na práci příjemnější.

                Díky. Mně osobně hashe nijak nevadí, ale tak jak to popisuješ, je to fér.

        2. Karel MinaříkAutor příspěvku

          Re: číslování revizí

          Právě že neumí. Mercurial má „RevisionNumber“, které je „krásně lineární“, ale:

          > Do not use them to talk about changesets with other people. Use the changeset ID instead.

          http://mercurial.selenic.com/…visionNumber

          A nějak tak bych řekl, že hlavním smyslem identifikátoru revize (commitu/chan­gesetu/etc) je právě to, bavit se o něm s někým jiným.

          1. Tom

            Re: číslování revizí

            Neumí a pak říkáte, že umí? Mercurial má lineární číslování a má i hashe.

            Lineární číslování má smysl, když existuje nějaký centrální repositář, tak je jednodušší se bavit o nějakých číslech než o hashi. Mercurial má neměnitelnou historii, takže se nestane, že by se nějak v centrálním repositáři ty čísla proházely.

            Viděl jsem u Git projektu, že prostě do každého commitu dali číslo, aby to bylo pro lidi jednodušší se na to odkazovat.

            Toto je prostě nevýhoda Gitu. Měl byste trochu změnit ten svůj přístup, že Git je to nejlepší co je a vše ostatní je špatný.

            1. Karel MinaříkAutor příspěvku

              Re: číslování revizí

              > Měl byste trochu změnit ten svůj přístup, že Git je to nejlepší co je a vše ostatní je špatný.

              Kde se tenhle dojem bere? Já začínám mít pocit, že je trestné říct, že ABC je _lepší_ než XYZ. Ale o Mercurialu není v článku ani slovo. Přiznám se, že už jsou pro mně ta obvinění z „fanatismu“ a kdovíčeho únavná.

              > Neumí a pak říkáte, že umí? Mercurial má lineární číslování a má i hashe.

              Ano, jak píšu i s odkazem, má lineární číslování, ale to je „soukromé“, platí (z logiky věci) jen v lokálním repositáři.

              Tak, jak to popisuje David Majda, mu může dávat smysl pracovat s „hezky lineárními“ čísly.

              Ale smysl ID revize je hlavně bavit se o ní s někým, což píšu v tom komentáři výše.

              Já proboha nijak nepomlouvám Mercurial nebo nechválím Git, že kašle na lineární čísla. Já se jen bojím, že si někdo přečte „Mercurial umí ‚hezká‘ čísla, to je supeeer“ a pak se bude divit, že to funguje _úplně_ jinak než si myslel. Možná vás udiví, jak často se to stává. Koneckonců, viz hezký příklad s mysteriózním .svnignore v kometářích k předešlému článku.

              A zadruhé, větší relevanci má podle mně bavit se o tagu nebo branchi. To soustředění na _revizi_ v DVCS nemá zas takový smysl.

  3. Martin Soušek

    subversion 2.0

    „je využívání Gitu jako Subversion 2.0, tedy nekoordinovaná práce v master větvi, která s sebou přináší konflikty a nekonečné „koleje“ merge commitů typu Merge branch ‚master‘ of …, jak hezky vidíte z obrázku níže.“

    Šlo by to více rozvést? Tedy co je konkrétně špatně a jak to má být správně? Co je nekoordinovaná práce v master větvi? Z obrázku bohužel nic „hezky nevidím“ :(

    1. Karel MinaříkAutor příspěvku

      Re: subversion 2.0

      > … nekoordinovaná práce v master větvi, která s sebou přináší konflikty a nekonečné „koleje“ merge commitů typu Merge branch ‚master‘ of …
      > Šlo by to více rozvést? Tedy co je konkrétně špatně a jak to má být správně? Co je nekoordinovaná práce v master větvi?

      Zkusím.

      Špatně je již to, že pracují více lidí rovnou v _master_ branchi, „tak jak jsme zvyklí ze SVN“. Tím pádem commitují, dostanou „rejected“, zaklejou, dají git pull, vznikne merge commit, to samé udělají po sobě tři další lidé, a máme z toho něco jako ten obrázek odkazovaný v článku.

      Špatně je to, že se pracuje v master branchi, protože práce pak není izolovaná. V Gitu není žádná režie s vytváření a slučováním větví (je to rychlé a snadné), takže je lepší pracovat v branchi.

      _Mimo jiné_ je pak právě daleko jednodušší stáhnout si změny z master, mergnout do master, rebasovat branch a pak ji začlenit do master. Zároveň není master pohyblivý terč, kam pořád někdo něco pushuje a já musím tudíž pořád aktualizovat ( git pull) – proto „nekoordinovaná práce“.

      Špatně je to, že se nevyužívají branche. Branche jsou killer feature Gitu.

      Je to lepší?

      1. ondra.novacisko.cz

        Re: subversion 2.0

        Nevím, co je killer feature, ale u nás v Subversion se běžně pracuje tak, že si vyrobím branch celého trunku, pak si stáhnu lokálně vše, na čem budu pracovat, a co potřebuju k přeložení projektu. Při branchování se mohu i přepnout v tomtéž WC.

        Následně si pracuji na své větvi a když to chci zamergovat, tak to nejdřív merguju k sobě a následně to přemerguju do trunku, s tím, že to pořeší i změny provedené mezitím. Pokud branch dále už nepotřebuju, tak ho smažu.

        Branchování přitom v SVN nic nestojí, bez ohledu na velikost stromu. Proto takhle může pracovat každý uživatel. Přímo v trunku se nepracuje, dělají se v něm jen hotfixy. A i tak lze případný hotfix v půlce práce branchnout, pokud je hodně složitý.

        Distribuovanost u repozitáře nám nechybí, naopak centralizace má výhodu, zvlášť pokud je server denně zálohován. Rychlost taky není problém.

        Je hezké kritizovat Subversion od člověka, který v něm neumí dělat :-D
        A to popisuju praktiky v Subversion 1.5, protože dvojka se ke mě ještě nedostala.

        1. Karel MinaříkAutor příspěvku

          Re: subversion 2.0

          > Je hezké kritizovat Subversion od člověka, který v něm neumí dělat :-D

          Sakra, já mám štěstí na jasnovidce. Z lógru taky věštit umíte? :)

          Nikde jsem nepsal, že v SVN nelze pracovat v paralelních větvích. Psal jsem, že se _leckdy_ a _leckde_ branche nepoužívají. V Gitu je používají i začátečníci. Myslíte, že to má nějaký reálný důvod, nebo jsou prostě všichni blbci?

          Tvrzení, že „branchování v SVN nic nestojí“ je úžasný vtip. Branchování ne, ale to mergování, to někdy bývá horší, co říkáte? :)

          1. ondra.novacisko.cz

            Re: subversion 2.0

            Leckdy kecy. Ano. Bože! Jsou to nástroje a někteří je používat umění, někteří ne. Není problém nástroje, že jej někteří neumí používat. Ano, GIT člověka možná nutí vytvářet branche, ale… kde?… Stejně nakonec musí v centrální databázi, protože nikdo nemá náladu lovit jeho kód v době, kdy náhodou onemocní, nehledě na to, že to má v náplni práce. U SVN má prostě napsáno, že před odchodem musí všechno commitnout a basta. Bez ohledu na to, jestli si vyrobil branch. Pořád je lepší, když commitem něco rozbije, než když to zapomene na lokále. V prvním případě se to dá přeplácnout starší revizí, v druhém případě nastupují crackovací nástroje (zaheslovaný comp je povinnost) nebo vytahování hesel z nemocného nešťastníka.

            „Tvrzení, že „branchování v SVN nic nestojí“ je úžasný vtip.“
            Vtipnej ste vy

            „Branchování ne, ale to mergování, to někdy bývá horší, co říkáte? :)“
            Mergování byl, je a bude vždycky problém. Mergování není věc verzovacího nástroje, ale věc mergovacího nástroje. Pokud jde o správné zamergování, tak já používám Eclipsovský diff, který samozřejmě všechno zvládne automaticky, a řeším jen konflikty. I tak se problémům nevyhnu, protože mergování prostě nelze vždy dělat hloupě bez znalosti kontextu zdrojovýho kódu. Ale v tom se obávám GIT mi nepomůže.

            Ale mergování přece není těžké. Vyrobí patch mezi dvěma revizemi v trunku a aplikuje ho na branch. Vyrobí patch mezi branchí a trunkem a aplikuje na trunk? Kde je problém? V čem vidíte problém? My to zvládneme bez podpory v SVN, protože repozitář jede (bohužel) na 1.4. Od vyšších verzí je tam podpora, že si to pamatuje čísla revizí od kterých byl merge proveden. I tak se to dá bez problému zvládnout, pokud si to jedno číslo, totiž číslo revize ve které se merguje, zapíše do komentáře. Nic víc.

            1. Karel MinaříkAutor příspěvku

              Re: subversion 2.0

              > Mergování byl, je a bude vždycky problém.

              Věřte nevěřte, nemusí to tak být.

              > Ale mergování přece není těžké. Vyrobí patch mezi dvěma revizemi v trunku a aplikuje ho na branch. (…)

              To ale nemluvíme o tomtéž mergování. Buďte na sebe tak hodný a přečtěte si o tom něco více:

              * http://www.kernel.org/…t-merge.html
              * http://book.git-scm.com/…merging.html

              a především to prosím v tom Gitu _vyzkoušejte_. Manuální „pamatování si“ merge base nebo eclipsovský diff je opravdu něco jiného…

              (Ad „nemocný vývojář“ – to je spíš otázka soudnosti každého a nějakých rozumných domluv, resp. „procesů“. To se commituje i napůl rozdělaná práce? A do jaké větve?)

              1. Martin Vanek

                Re: subversion 2.0

                No ja stejne jako novacisko nechapu jak muze git byt prospesnejsi pri mergeovani nez jakakoliv konkurence. Predpokladam, ze se nebavime o trivialnim mergi bez konfliktu. To ma git umelou inteligenci, ktera vydedukuje spravny vysledek z pruniku dvou (a vice) zmen stejneho kodu? Hadam ze ne, proste jen prodpokladate styl vyvoje kdy se nikdo nikomu nehrabe v kodu a kazdy si jede „na vlastnim pisecku“. Kombinace prace nad lokalni repository a „navadeni“ k branchovani (kterehoz uzitecnost je v realu skutecne casto podcenena) vede ve vysledku k potrebe vetsiho pushe do centralni repository a tim padem k pravdepodob­nejsimu vytvoreni megakolizi a o ty tu jde predevsim, ostatni je syntakticka omacka.

                  1. Martin Vanek

                    Re: subversion 2.0

                    Predpokladam ze lokalni zmeny jednou popupuji na central at uz head nebo branch. Do toho sameho ovsem sve zmeny pushuji i ostatni, takze cim vetsi kumul zmen, tim vetsi legrace s konflikty. Tohle nemuze vyresit zadny system at uz distribuovany nebo centralni ci jakykoliv.

                    1. Martin Malý

                      Re: subversion 2.0

                      Položím otázku téměř filosofickou: Kde přesně je v distribuovaném decentralizovaném systému ten „central“, kam „jednou“ poputují „lokální změny“?

                      1. Martin Vanek

                        Re: subversion 2.0

                        Takze vy v gitu nesdilite kod s nikym jinym, nebo mate nekde v metadatech gitu IP adresy peeru?

                        1. Martin Malý

                          Re: subversion 2.0

                          Zkuste nejprve odpovědět na položenou otázku, možná zjistíte, že to není jen „slovíčkaření“, ale že je v ní odpověď i na další Vaše připomínky v této diskusi. Napovím analogií: Pro středověkého člověka byla Brunova představa mnohosti světů, v němž neexistoval žádný „střed vesmíru“, okolo něhož by se zbytek točil, mentálně neuchopitelná – neměla žádný pevný řád, a mozek tíhne k řádu, kterého se může držet.

                          1. Martin Vanek

                            Re: subversion 2.0

                            Dekuji za prirovnani ke stredovekocloveku, nicmene obsah vasi lokalni repository je celemu vesmiru platny stejne jako surmovce cerite supernova. Bez well known spolecneho remotu (tedy centralu) se proste neobejdete.
                            Uplne stejne jako clanek juchajici nad v podstate trivialnim blbnutim s branchema (opet podotykam, ze jsou obvykle tezce nedoceneny a poduzivany) a zastirajici fakt, ze skutecny problem neni ve snadnosti spravy vetvi, ale v reseni konfliktu, zastirate ted vy fakt, ze k realne praci byt i jedineho cloveka na vice strojich, potrebujete spolecny remote. Pro takovy trivialni pripad by vam takrka stacil „stary spatny“ sdileny filesystem, pac kolizi sam se sebou snad vyrobite ztezi. K cemu by byl takovy github?

                            1. Martin Malý

                              Re: subversion 2.0

                              Pro samou snahu nachytat někoho na švestkách a dokázat, že předměty těžší než vzduch nemohou létat, jste bohužel odpověděl dřív než jste se zamyslel, že? Tak jinak: Já nic nezastírám (a tím míň praktickou užitečnost sdíleného remote prostoru), já se vás ptám, kde chcete v decentralizovaném distribuovaném systému najít tu „centrální autoritu“, na niž se odvoláváte, a která by dle vás měla řešit megakolize, které vzniknou tam, kde se nashromáždí moc commitů? Je opravdu tak těžké přijmout představu, že jich může být víc, že mohou vznikat a zanikat podle potřeby, spojovat se a zase rozdělovat? Že v takovém systému nemusí vznikat konflikty takového typu, jaké popisujete, protože je možné nastavit procesy jinak? (Technicky to tu popsal Inkvizitor.)

                              Zkuste na DCVS nahlížet jako na vývoj Linuxu/GNU (nemyslím teď samotný kernel): Nemá „centrální repository“, má stovky repository na tisíce programů, a z těchto repository si vybírají správci balíčků a distribucí potřebné soubory pro své repository. A když se správce jednoho konkrétního balíčku rozhodne, že si udělá kolem svého SW distribuci, tak nebuduje celou paralelní vývojářskou síť, v níž by on byl CENTRAL, ale stáhne si od ostatních to co potřebuje, vyřeší si konflikty – a postupuje tak při každém update. Je to stejný princip, jen o úroveň výš.

                              1. Martin Vanek

                                Re: subversion 2.0

                                Svestky stranou a „centralni autoritu“ na reseni kolizi jste si prave vymyslel vy. Konflikt si v kazdem me znamem VCS resi nestatstnik ktery zrovna merguje svuj kod s kodem ostatnich.

                                Inkvizitor ve svem informativnim sedm radku dlouhem (prispevku narozdil od vaseho opletenem obecnymy a nabubrelymy vyroky) o pouzil sestkrat vyraz verejny/centralni repository. To celkem mluvi za sebe.

                                To co popisujete v druhem odstavci popisuje situaci kdy je pouze jednosmerne odsavano z mnoha ruznych remote repositaru a poreba verzovani je 0.

                                1. Martin Malý

                                  Re: subversion 2.0

                                  Ocituji: „Predpokladam ze lokalni zmeny jednou popupuji na central at uz head nebo branch. Do toho sameho ovsem sve zmeny pushuji i ostatni, takze cim vetsi kumul zmen, tim vetsi legrace s konflikty.“ Otázka: „Kde je v DVCS ten centrál, do kterého pushují i ostatní?“ (Pomůcka: Inkvizitor hovořil o vybírání shora, nikoli o tlačení zespoda…)

                                  1. Borek Bernard

                                    Re: subversion 2.0

                                    Martine, centrální repozitář vyplývá z kontextu nastoleného diskutujícími v tomto threadu (snaží se zjistit, jak jim git pomůže s mergováním v svn-like workflow). Na obecné úrovni máš samozřejmě pravdu, jen mám pocit, že o tom toto vlákno není (nebo aspoň do určitého okamžiku nebylo :)

                                2. Inkvizitor

                                  Re: subversion 2.0

                                  Pojem „centrální“ jsem možná nezvolil moc vhodně. Zrovna tak jsem mohl napsat „produkční“, „oficiální“, „referenční“… Rozdíl je asi hlavně v tom, že role „hlavního“ repozitáře není podepřena nějakou automaticky danou prioritou jakožto vlastností VCS, ale právě procesem, který dodržují lidé (a případně nějaké automatizované nástroje).

                                  Co se týče věcné stránky sporu, domnívám se (jako někteří jiní), že zásadní výhoda z hlediska správy konfliktů plyne právě z nahrazení operace merge operacemi rebase a cherry-pick, ikdyž jsou i nevýhody; třeba časová režie opakovaného rebase a ztráta informace při umělé linearizaci historie projektu.

                    2. ijacek

                      Re: subversion 2.0

                      Aha, takze problemem jsou velke lokalni zmeny, ne lokalni repository. V tom pripade to ovsem je vec politiky tymu, ne VCS.
                      Ze zkusenosti musim rict, ze v tomhle zrovna SVN praci vubec neusnadnuje – viz castecne commity z jednoho souboru v minule diskuzi. Aneb kdyz chci v SVN dostat na server aspon neco, tak to stoji hodne trapeni, vykopirovavani atd…
                      A dovedu si predstavit, ze by to slo delat jeste lepe nez v gitu :-)

                      1. Martin Vanek

                        Re: subversion 2.0

                        Tak na zastecne komity je tu integrace s IDE, ale o to ted nejde. Jde o to, ze jsem z clanku a s diskuze mel dojem ze git prinasi neco genialniho v problematice mergeovani konfliktu oproti svn (a potazmo s cvs) a jak to tak vypada jedna se o stale samy (neresitelny) problem, az na to, ze v gitu musim diky/kvuli distibuovanosti navic pushit, tedy o prikaz vice, coz se asi muze u nekterych typu projektu hodit, nicmene v korporatnim pouziti mi prijde spis prace navic.

                        1. ijacek

                          Re: subversion 2.0

                          Uz ten vyraz castecny commit napovida, ze by ho mohl resit nastroj, ktery dela commity, ale proti gustu…
                          Nejlepsi reseni konfliktu je takove, kdy k nim nedochazi – napriklad tak, ze si vyvojari muzou predat casti kodu mezi vetvemi jeste nez dojde k mergovani do nejakeho spolecneho trunku. Udelal jsem si ted maly test, SVN 1.6.6 to nezvladlo pokud jsem nezadaval rozsahy revizi. V kombinaci s tim, ze mi TSVN neukaze co kam jsem uz mergoval je to dost pruda.
                          Cili SVN mi moji snahu predchazet konfliktum nijak neusnadni, naopak musim se snazit ja, aby to nervalo v pripadech, kdy se o konflikt nejedna. Git udelal presne co jsem chtel a nestezoval si na nic. Takze asi tak.

              2. František Kučera

                Mergování

                >> Mergování byl, je a bude vždycky problém.
                >Věřte nevěřte, nemusí to tak být.

                „Mergování“ je problém z principu. A nezachrání to ani sebegeniálnější verzovací systém – leda že by to byla umělá inteligence, ale to by za nás pak počítač mohl rovnou programovat a my bychom nemuseli dělat nic. :-)

                Ono totiž u slučování nejde až tak o tu technickou/formální stránku, ale o tu obsahovou – že vůbec máme různé verze nějakého souboru (souborů) a ty je potřeba sloučit. Následně je potřeba vyzkoušet, jestli ta sloučená verze jde zkompilovat a otestovat ji – to sloučení může sice krásně proběhnout, ale při kompilaci se např. ukáže, že kolega přepsal nějaké rozhraní a moje třídy, které by ho měly implementovat ho neimplementují (třeba tam chybí nějaká metoda nebo je přejmenovaná)… a to jsou věci o kterých verzovací systém neví a ani nemůže vědět → to je pak práce pro člověka.

                IMHO je lepší se nejdřív snažit:

                – aby si jednotliví vývojáři „nelezli do zelí“ – nějakou ucelenou část aplikace vyvíjí v jednu chvíli jen jeden člověk.

                – pokud to není možnné, tak se udržovat co nejvíc „online“ mít vždy aktuální verzi a nedopustit, aby se větve jednotlivých vývojářů příliš „rozjely“.

                A až když to nejde, tak nastupuje to „mergování“ – což je ale práce navíc a opruz (z výše uvedených důvodů) vždycky – i s tím úžasným Gitem nebo Mercurialem. Je to víc o organizaci a rozvržení práce než o verzovacím systému…

                1. Karel MinaříkAutor příspěvku

                  Re: Mergování

                  > „Mergování“ je problém z principu. A nezachrání to ani sebegeniálnější verzovací systém (…)

                  Ano, v tom máte samozřejmě pravdu. (Také nikde nepíšu, že by Git byl nějak „geniální“, to se objevilo u někoho jiného až v diskusi. Já jen psal že práce s větvemi je v Gitu snadná a rychlá.) Ale především jsem měl na mysli spíše věci jako je:

                  * http://stackoverflow.com/…eintegration
                  * http://blogs.open.collab.net/…on-merg.html

                  a „obecný dojem“, který mám já i řada kolegů, že Git zvládá mergovat jednu _i více_ větví lépe, než (typicky) SVN. Ze svědectví co jsou na internetu viz např. Digg: http://about.digg.com/…gggit-part-1. Pochopitelně, na to se dá říct, že jsme všichni fanboys a blbci a že to určitě s SVN neumíme etc etc.

                  Kdyby si někdo dal tu práci a složitější merge vyzkoušel v Perforce, Gitu, CVS, SVN, etc a publikoval výsledky, bylo by to úžasné. Ale všichni víme, že to je _mnohem_ náročnější než po sobě poštěkávat v diskusi pod článkem.

                  (Jen poznámka k „… to jsou věci o kterých verzovací systém neví a ani nemůže vědět …“ > Máte pravdu. Ale mohly by o tom vědět třeba testy, a to je pak ve spojení s continuous integration jiná hra, byť nepomůže s mergováním. A ve spojení s „binary bug search“ Gitu ( git bisect) je to při hledání chyby zase něco jiného.)

                  1. Borek Bernard

                    Re: Mergování

                    Super komentář, který by možná měl být přímo v článku – a na něco podobného jsem se vlastně včera večer chtěl zeptat taky a jsem rád, že diskuze došla až sem.

                    Mně totiž taky připadá, že dokud někdo neudělá normální a objektivní porovnání stejných scénářů v různých VCS, zůstane rétorika o snadném mergování jen rétorikou. Asi by nebylo těžké prokázat, že mergování v SVN je v některých případech přinejmenším problematické (tvůj druhý odkaz by mě od SVN asi úplně odradil), ale co třeba Perforce? TFS? Je mergování v gitu při podobném workflow jednodušší nebo na stejné úrovni? Nebudou naopak některé centralizované systémy dokonce lepší kvůli explicitnímu uchovávání informací např. o přejmenovaných souborech?

                    To jsou asi všechno otázky, na které se nedá odpovědět jednou větou, ale právě na jejich základě bych se rád rozhodoval. Což takhle po Novém roce zkusit nějaké takové porovnání udělat?

                    1. Karel MinaříkAutor příspěvku

                      Re: Mergování

                      > (…) co třeba Perforce? TFS? Je mergování v gitu při podobném workflow jednodušší nebo na stejné úrovni? (…)

                      TFS prakticky vůbec neznám, a o Perforce se traduje, že má _velmi_ silnou podporu mergování. _Údajně_ je Git na stejné úrovni. (Oba jsou ale komerční sw, pro pořádek.)

                      > Což takhle po Novém roce zkusit nějaké takové porovnání udělat?

                      Já se, jako obvykle, za Git klidně zůčastním.

                  2. František Kučera

                    Re: Mergování

                    >> „Mergování“ je problém z principu. A nezachrání to ani sebegeniálnější verzovací systém (…)
                    >Ano, v tom máte samozřejmě pravdu.

                    Já jsem právě reagoval na „Věřte nevěřte, nemusí to tak být.“
                    Ale nechme toho, to je slovíčkaření.

                    > Pochopitelně, na to se dá říct, že jsme všichni fanboys a blbci a že to určitě s SVN neumíme etc etc.

                    Nezastávám se Subversionu – sice si nemyslím, že by byl úplně odepsaný a měl by zmizet, ale distribuované systémy jsou (většinou) výhodnější. Nezastávám se tu ani Mercurialu, který je můj oblíbený. Ale abych přece jen trochu přispěl k diskusi, napsal jsem: Verzovací systémy – svn, git, hg – svatá válka?

                    > Kdyby si někdo dal tu práci a složitější merge vyzkoušel v Perforce
                    S P4 jsem dělal asi tři roky… a občas jsem si říkal „proč radši nepoužíváme ten Subversion“ :-) Dneska bych dal asi přednost Hg (případně Gitu) před Perforcem a to nejen kvůli tomu, že za P4 se musí platit. Zajímavější by spíš bylo vyzkoušet si reálnou práci s ClearCasem – ale ne s ním samotným, ale s celou tou sadou nástrojů od Rationalu (IBM) – absolutní integrace od IDE, přes verzovací systém, „Bugzillu“ až po testovací nástroje.

              3. ondra.novacisko.cz

                Re: subversion 2.0

                „To se commituje i napůl rozdělaná práce? A do jaké větve?“

                Ano!

                Pokud je zřejmé, že se to do konce dne nestihne, pak si vývojář vyrobí branch (v Branches má každý právo si založit libovolné množství větví), switchne se do něj a commitne to do něj. Operace přes GUI na jednu nebo dvě minuty.

                To jestli se vyrábí centrální, nebo lokální branch je jedno. Síť je relativně rychlá a výhoda centrální branche je v tom, že centrál je denně zálohován a na práci vývojáře může klidně někdo navázat.

            2. Martin Malý

              Re: subversion 2.0

              Jen k tomu „nemocnému vývojáři“ – jednak to je opravdu otázka nastavení procesů, jak píše Karmi, ale spíš by mě zajímalo, jak s tímto přístupem chcete nějak rozumně vyvíjet SW, na kterém se podílí několik desítek lidí na různých místech v různých časech a ve volných chvílích (typicky všechny komunitní projekty)? Čím dál víc firem opouští model „vývojář sedí osm hodin v kanceláři u PC a odevzdává denně svých XXX řádků kódu“, přechází z centrálně řízených a plánovaných projektů na jiné způsoby (decentralizace, iterace vývoje místo plánu apod.) a tam je Vámi popsaný model poněkud anachronický a kontraproduktivní.

              1. ondra.novacisko.cz

                Re: subversion 2.0

                To je hezká představa, ale utopie. I když programátor pracuje vzdáleně, přes VPN a kdy se mu zachce, stejně by měl mít povinnost jednou denně commitnout „někam“ svých XXX řádků. Už proto, aby jeho práce byla nějak kontrolovatelná. V naší firmě provádíme Scrumování a sprintování, což se vyznačuje zejména každodenní zhodnocení práce před celým týmem. Je to v celku osvěčená technika (standup trvá cca 15minut, takže žádné velké zdržování). Pokud se pracuje externě, pak se to řeší přes video nebo hlasovou konferenci, v horším případě přes Jabber.

                Právě že achylovou patou celého OpenSource programování je ten, že na programu dělá blíže nezjištěné množství vývojářu, bez zřejmé koncepce, bez zodpovědnosti, jako konička se svým vlastním přístupem k problému, který není vždy žádoucí. Chápu, že pak existuje nutnost nějakých nástrojů, jak tyto vývojáře nějak sjednotit. Nadruhou stranu, tam bych viděl problém celého Linuxu, tedy roztříštěnost, a tomu ještě napomáhá distribuovaný verzovací systém.

            3. Inkvizitor

              Re: subversion 2.0

              Merge je obecně zlo, někdy možná nutné, ale většinou nikoliv. Dá se to vyřešit i jinak – např. každý vývojář má svůj lokální repozitář a veřejný repozitář, do kterého dělá pravidelně push z toho lokálního, na kterém dělá pravidelně rebase oproti centrálnímu repozitáři. Lokálně si vyřeší konflikty oproti centrálnímu repozitáři a správce centrálního repozitáře přejímá commity z veřejných repozitářů všech vývojářů pomocí operace cherry-pick. Tak se vyřeší případná absence vývojářů, kteří uveřejní commity, které považují za finální, předejde se drtivé většině špatně řešitelných konfliktů a historie centrálního repozitáře zůstane krásně lineární. Výhoda distribuovaných VCS je právě v tom, že v nich jde takto nastavovat procesy podle potřeby.

        2. setapoux

          Re: subversion 2.0

          svn copy blabla/trunk blabla/branches/my­branch – tohle, že nic nestojí? No nevím…

          Na druhou stranu buďte všichni rádi, že Vás nenutí používat ClearCase.

          1. ondra.novacisko.cz

            Re: subversion 2.0

            1) používám GUI
            2) Vlastní operace kopírování neprovádí, pouze vytvoří něco jako symlink.

        3. ijacek

          Re: subversion 2.0

          > Branchování přitom v SVN nic nestojí, bez ohledu na velikost stromu

          Sam pisete, ze si branch musite stahnout nebo prepnout. Prvni je prinejmensim linearni ve velikosti kodu, druhe linearni v poctu adresaru. Na male projekty to staci, ale u velkych to zacne byt docela „drahe zadarmo“. Pak uz si rozmyslite, jestli branch udelate nebo ne. Rozhodne je to neco, v cem SVN usera omezuje.

          1. ondra.novacisko.cz

            Re: subversion 2.0

            Používám GUI. Tortoise SVN tohle zvládne přes kontextové menu v exploréru. Stačí si jen zvoli jméno branche. Zbytek se udělá samo. Nedávno jsem to udělal v repozitáři, který má několik desítek tisíc souborů, číslo revize má na začátku pětku a další čtyři čísla a celý repozitář má kolem půl giga. Operace trvala asi 5sekund, přičemž mám k dispozici síť 512KB.

            WC byla samozřejmě před branchem už stažení.

            1. ijacek

              Re: subversion 2.0

              Jo, tak samotne zalozeni 5s jeste jde. Switch do existujici ale trva mnohem dele, radove minuty. A nevisi to jen na pripojeni. Nevim cim to je, mozna ze velikosti rep, nase ma 13GB…

            2. Hok

              Re: subversion 2.0

              Nechapu jak nekdo muze rikat, ze prace s SVN je rychla, nebo nedej boze prijemna. Delam na trosku vetsim projektu ve kterem mame hodne „hlavnich“ vyvojovych vetvi + spoustu personalnich.

              Ano, da se s tim pracovat. Ale je to opravdu neprijemny zazitek. Navic pokud dojde k situaci kdy je potreba zamergovat jednu z vyvojovych vetvi do trunku tak je to vetsinou prace pro jednoho zkuseneho programatora na nekolik hodin – a to i diky tomu, ze svnku proste spousta veci strasne trva. Nemluve o situaci kdy z vyvojove vetve nekdo primergoval prioritne. (A ne svn:mergeinfo je sice fajn, ale nic moc to neresi)

              A nedej boze kdyz potrebuju behem merge kouknout na historii nejakeho souboru, to si nekdy pockam i par minut.

              No celkove po precteni tohoto vlakna jsem nabyl dojmu ze jsou jenom dve moznosti jak muze vesmir fungovat. Bud s SVN pracuju (a dalsich 150 lidi v nasi firme) strasne blbe, nebo nekteri z prispevovatelu s SVNkem nikdy nepracovali na vetsim projektu. (A priznavam ze pripoustim existenci obou vesmiru zaroven)

              1. ondra.novacisko.cz

                Re: subversion 2.0

                Zkuste připustit variantu, že spoustu lidí pracuje v SVN, aniž by přesně věděla, jak se v něm pracovat má.

                Doufám, že třeba víte, že mergovat do trunku je nutné tak, že nejprve zamerguju změny v trunku do svého branche a pak to přemerguju do trunku. Tím se vyhnete všem těmto problémům, o kterých píšete.

                A pomalost jsem nepoznal ani na projektu, který má desítky tisíc souborů a desítky tisíc revizí. Pomalost ve smyslu běžná reakce na příkaz do jedné dvou sekund, při významěnjších operací (jaku merge stromu) do deseti sekund. Nevím, jaké máte vy zkušenosti s časy, ale tohle jsou pro mne běžné časy.

                Historie… teď jsem to zkoušel, na VPNce, rychlost downloadu 512kB. nechal jsem si vytáhnout historii celého stromu včetně branchů a trunků za poslední měsíc filtrovaný na moje jméno. cca 15s, hlavně díky pomalosti linky (filtrování totiž provádí až klient). Revizí tam bylo mnoho. Na páteři by to bylo za doslova pár sekudu.

                Nevím, o jakých časech mluvíte.

                1. ijacek

                  Re: subversion 2.0

                  Co se tyce casove narocnosti, asi nezbyva nez to uzavrit s tim, ze jen v teto diskuzi je nas nekolik, kteri maji svn strasne pomale a to ze vam to jede rychle nas nespasi. Mozna je to velikosti rep nebo strukturou adresaru, kdo vi, ale holt je na to svn nepouzitelne kdezto git ano.

                  > nejprve zamerguju změny v trunku do svého branche a pak to přemerguju do trunku. Tím se vyhnete všem těmto problémům

                  Tohle je presne styl SVN, ze vas to nuti delat veci nejak, jen aby to fungovalo. Ve vysledku porad obchazite nejake problemy a jen si tim zpusobujete dalsi. Napr. zde, kde je nutne delat 2× tolik casove umorne prace s presne definovanym postupem, zadne merge mezi vetvemi atd. protoze jinak je mergeinfo k nicemu.

                2. Hok

                  Re: subversion 2.0

                  Ano pripoustim, ze spousta lidi s SVN pracuje … rekneme neinformovane. Ale troufam si tvrdit, ze toto u nas vetsinou problem neni.

                  Ano vim, ze „je nutne“ zamergovat zmeny z trunku do branche a potom teprve primergovat. Ale to nic nemeni na tom ze obcas potrebujem prioritne commitnout revizi z branche na trunk mimo predem dany rozvrh. A to je vetsinou misto ve kterem se SVN system zacina rozsypavat jak domecek z karet. (Prehanim, nerozsype se, jenom zacnou byt veci trosku komplikovanejsi)

                  A bohuzel nevim o jakych casech mluvite Vy. Kdyby to v mem pripade bylo tak jak rikate, tak bych si na svn asi ani tolik nestezoval. Ale v nasem pripade to je proste radove pomalejsi. Show history zabere i nekolik minut, kdyz ma zrovna den (a rychlosti spojeni to rozhodne neni).

                  1. ondra.novacisko.cz

                    Re: subversion 2.0

                    To mergovani do branche je hlavně proto, aby se pořešili změny v trunku v rámci Vaši branche. Dělá se to proto, ne že by to SVN nezvládal, nebo že je to nějaká obchůzka. Dělá se to proto, že žádný merge není tak inteligentní, aby vždy zamergoval správně strukturu zdrojaků. Proto se používá postup

                    1) Zamergovaní trunku do branche
                    2) Přeložení
                    3) Vyzkoušení
                    4) Commit
                    5) Překlopení branche do trunku.
                    6) Commit v trunku.

                    Pokud děláte commit přímo z branche do trunku, koledujete si o malér už proto, že nemáte představu, jaké změny tam kdo udělá mezi tím, co uděláte v trunku update a commit. Ano pak nastane varianta, update, merge, update, commit, která v závislosti na změně mezi mergem a druhým updatem nemusí dopadnout dobře. Protože změny, které tam někdo provedl vlastně patří před první update, zatímco vy je uděláte až po merge, což je z pohledu historie špatně. Pokud jsou ty změny závislé, pak se to rozbije. Bohužel, neumíte mergovat, není to problém SVN.

                    Naopak výše uvedený postup způsobí, že pokud mezi merge a commitem do trunku dojde ke změne, musíte se vrátit k bodu jedna a celý postup opakovat. Proč? Protože je to konflikt. Výhodou ale je, že nemusíte opakovat celý merge, protože ten částečný už máte udělaný, mergujete jen ty změny, které proběhly mezi body 1. až 7. během prvního kolečka.

                    Tohle jsou všechno problémy dané tím, že víc lidí pracuje na tomtéž. Všechny tyhle konflikty musíte řešit, ať už implicitně, nebo explicitně. A pokud vám vadí množství těch kroků. které musíte udělat,… linuxák by si měl být schopen napsat skriptík ne? Takový, který to zvládne vše automaticky (kromě bodů 2 a 3). bez další kooperace s uživatelem.

                    Nevěřím, že GIT zvládne mergování lépe. Určitě si musíte nejprve updatnout lokální repozitář, násleně zamergovat svůj branch a pak to poslat na server ne? Tudíž totéž v bledě modrém.

                  2. vandrovnik

                    Re: subversion 2.0

                    Kdysi po nějaké aktualizaci serveru začalo být i moje SVN pomalé – ukázalo se, že za to může volba KeepAlive v httpd.conf, která po aktualizaci byla nastavená na Off. S nastavením na On je rychlost vyšší minimálně o řád.

    2. BostX

      Re: subversion 2.0

      Tiez som mal na zaciatku tento problem. Odpoved je jednoducha:
      1. Commituj/bran­chuj tak casto ako chces hoci aj kazdu bodkociarku (niekedy to ma vyznam pri bisecte) ale nie do upstreamu, ale lokalne, do tvojich privatnych branchov
      2. Na sync lokalnych branchov s upstreamom nepouzivaj ‚git merge‘ ale zasadne ‚git rebase‘
      3. Nauc sa pouzivat ‚git commit –amend‘, ‚git rebase –interactive‘ a ‚git cherry-pick‘

  4. Bretislav Wajtr, ml.

    GIT vs Perforce

    Zajimalo by me jak by jste porovnali GIT versus Perforce… pokud teda nekdo znate oba systemy. Zatim jsem ze dvou jiz napsanych clanku o Gitu vypozoroval, ze toho ma s Perforcem celkem dost spolecneho. (Doufam ze me ted znalci neukamenuji). Pravda ze Perforce nam tedy obcas rika „jak“ veci delat, ale zatim to tedy beru pozitivne, protoze nas je opravdu mnoho a kodu uplne silene. Napr. uz si nedokazu predstavit praci bez tzv. Changelists – (pravdepodobne to same co je v gitu Index) – zmeny se daji rozdelit do changelistu a submituje se potom jeden changelist jako celek. Krasne se pak hleda co se se souborem delo… ma GIT napr. nejake vymakane GUI? Ptam se jen kvuli vyhledavani zmen… na zbytek staci radka, ale pohodlny search je v urcitych situacich podstatna vec… Prosim nereste otazku penez… Cena Perforcu ho odsuzuje k vetsim projektum, ale to me nezajima… ted resim problem „co je lepsi na co“, ne „kolik za to dam“

    1. Karel MinaříkAutor příspěvku

      Re: GIT vs Perforce

      > jak by jste porovnali GIT versus Perforce

      Perforce znám jen na úrovni Hello World, neporadím. Slyšel jsem ale o migracích Perforce -> Git, jmenovitě u Google Android.

      > ma GIT napr. nejake vymakane GUI?

      Samozřejmě, celou řadu:

      * Nativní GUI klient
      * TortoiseGit
      * QGit
      * GitX (Mac OS X)
      * Eclipse plugin
      * Netbeans plugin
      * webová rozhraní (Gitweb, Gitorious, atd)
      * a mnoho dalších

      1. abtris

        Re: GIT vs Perforce

        Jeste bych pridal ze podpora Gitu je v IDEA a WebIDE od JetBrains,
        a osobne mam rad klienta tig pro console (pekny a prehledny) http://jonas.nitro.dk/…screenshots/.

        Naopak treba ten NetBeans plugin je skoro nepouzitelny, umi jen par zakladnich prikazu a jeste mi to docela padalo.

        29. 12. 2009 8:30 redakčně upravil Martin Malý, důvod: Autor komentáře požádal o odstranění špatně zadaného odkazu
  5. kaja47

    aee4bd941f8b4d9e39210c06c44fcb71

    Doteď jsem Git používal jako velice hloupé verzovátko. Teprv tenhle článek mi otevřel oči.

  6. pr.rybar

    Bazaar

    Ma niekto nejake skusenosti s pouzivanim RCS Bazaar? Ako je na tom v porovnani s GIT? Chcel by som vediet nazor niekoho, kto realne oba systemy nejaky cas pouzival.

  7. uf

    celkove

    K cele diskusi:
    Na rozdil od jinych se v clanku upozornuje na vlastni firmu-skoleni jen jednou. Jsou jine weby, kde je to podstata clanku.

    Kolik vas dela s Mercurialem? Me se libi.
    Je distribuovany.
    Pro release, buildy a integraci je stejne potreba mit hlavni repozitor, kam clovek da opravdu otestovane OK vysledky, pak nejaky pro caste jeti testu a kazdy clovek by asi mel mit svuj pracovni a svuj zakladni, kde jsou veci pustitelne dal.

    1. Almad

      Re: celkove

      My ve firme jedem na gitu, ale na osobni projekty pouzivam hg. Nevidim mezi temi projekty nejaky zasadni rozdil, akorat s hg se pracuje primeneji.

      git je mocnejsi, ale to v 99%tech nepotrebuju a naopak me casto zdrzuje jeho UI.

  8. Jan Sládek

    Díky za skvělý článek i seriál

    Karmi, děkuji za další skvělý díl seriálu. Tvoje vysvětlení GITu chápu i já (na podobné věci poměrně antitalent) a začínám tak poznávat sílu a krásu GITu. Jen tak dál!

  9. Dundee5

    Díky

    Díky Karmi! Tenhle seriál čtu opravdu velmi rád a doufám, že si ho přečte i hodně project managerů, aby se Git v českých IT firmách trochu víc prosadil.

  10. veros

    Díky

    Zdvořile prosím redakci o zřízení tlačítka „Mě se líbí“, ať nemusím zaplevelovat diskusi.

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3141