Vlákno názorů k článku
GIT: distribuovaná správa revizí

Pokrok je posilat patche emailem at si maintaner sam vyresi konflikty u sebe pri comittu :-) Takze GIT je vlastne lepsi diff plus par mv/cp pro udrzeni vice branchu.

Pochopitelne maintainerovi nic nebrani aplikovat pouze nekonfliktni changesety (ostatne presne takhle to funguje v realnem svete - vyvojar ma obvykle u sebe dalsi vetev nebo repository "pro upstream", "for-Linus", apod., ktera obsahuje aktualni stav upstreamu + lokalni zmeny urcene pro upstream). Konflikty resi vyvojar, ne upstream maintainer.

Hlavne git (nebo jakykoli distribuovany VCS) prinasi jednu podstatnou vyhodu - muzete snadno commitovat samostatne zmeny i uprostred rozdelane prace (zmeny typu: upravuji neco velkeho, ale pak si vsimnu jednoradkove logicke chyby - tuto muzu opravit jako samostatny commit/changeset, aby byla jako takova samostatne popsana a samostatne aplikovatelna do jinych vetvi). Cili commit (changeset) je logicky ohraniceny celek, ne "vse co jsem udelal za dnesek", jako v CVS.

-Yenya

Nechápu, jak se v tomhle liší GIT třeba od SVN. (P.S. nevím, co všichni máte s CVS, to už je dávno mrtvé...)

V SVN má taky každý svůj samostatný repozitář, kde si může řádit, jak se mu zlíbí a do upstreamu protlačit až patche, které považuje za finální? To mi asi něco uniklo.

Nemá.

(Existuje ale taková polodistribuovaná nadstavba SVK, která to umí)

Ano muzete mit vlastni branch a radit jak chcete. Nebo mi neco uniklo? Pouze protlacit patch do finalni verze musite sam, vcetne reseni konfliktu, misto maintaneru, ktery to u gitu udela za vas. Ale i v SVN neni problem, aby vasi privatni vetev spojil nekdo jiny.

Udělat vlastní branch je jedna věc a mít X vlastních nepublikovaných branchů u sebe a řádit i v mainu je trochu něco jiného.

Možná se budete divit, ale pro své soukromé účely jsem se vrátil k CVS. Vyhovuje mi ze všeho nejvíc. Pokud si spravuji své kódy sám, mám prostě v jednom adresáři repository, nad kterým můžu, ale _nemusím_ mít CVS server. Nemusím rozcházet pro mě zbytečný server, data čtu v případě mě pouhým nasměrováním na adresář. SVN je těžkopádnější, a není k dispozici pro takovou řadu platforem, jako CVS. CVS repository je lidsky čitelné a spravovatelné, když by bylo nejhůř, u SVN ne. Navíc výhody SVN (které mi stejně přijde jen jako CVS 2.0) oproti CVS nejsou natolik podstatné, aby stály pro mě za řeč.

Díky tomu není problém mít u sebe několik CVS repository (třeba i na flashce), a mít jedno hlavní a pak třeba lokální na projekt, čímž se přesně dostávám k distribuovanému způsobu práce s CVS - něco jako tu bylo chváleno u GITu. Lokální změny každou chvíli commituji do dočasného CVS repository (v podstatě lepší záloha a možnost libovolného vracení se zpět včetně všech detailů co jsem kdy udělal), odladěnou část projektu pak přesunu do hlavního repository, kde mám funkční verze a hlavní milníky. Stejným způsobem může vyvíjet skupina lidí - a pomocí CVS mít velmi dobrý "distribuovaný" vývoj. Klidně mohu mít speciální dočasné repository pro každý projekt. U SVN to hodně dře.

Presne pro tyto ucely pouzivam SVN. Vyvoj mam v trunk, experimenty delam v branches a kdyz se mi neco hodne moc povede, tak to dam do tagu :-D. A server taky nemam... repozitar mam v jednom adresari v home. A domnivam se ze tezko najdete system, kde SVN nepujde rozchodit (Linux, Windows, Solaris, OpenSolaris a *BSD jsou v pohode).

Mám CVS repository jako součást projektu. Tedy projekt je adresář, pod který jsou podadresáře cvs, src, bin, atd.. Když chci pokračovat na projektu jinde, zabalím celý adresář a mám to se vším všude včetně cvs repository a můžu bez jakýchkoli potíží pokračovat jinde na jiném počítači včetně práce s CVS repository.

SVN nefunguje na Windows 9x/ME a nikdy už fungovat nebude.

SVN nefunguje na Windows 9x/ME a nikdy už fungovat nebude. To je skutecne zasadni nedostatek, na S/360 to take nefunguje? :)