Přechod Subversion (SVN) → Git

Škoda, že mi takhle zavřeš cestu k svn:externals, který s oblibou pro natahování Nette do projektů používám ;)

externals mi budou taky chybět, není tam za ně nějaký ekvivalent?

Mám pocit, že po přepnutí na Mercurial by mělo SVN stále fungovat (http://texy.googlecode.com/svn/trunk/) a Mercurial umí exportovat do SVN, tak by se to dalo synchronizovat.

jasir napsal(a):

Zahlédl jsem něco na twitteru a celý den si říkám: ať je to git, ať je to git a bum ho!, mercurial :-(

V čem se zejména liší? Ať už repozitáře nebo nástroje?

David Grudl wrote:
Klíčový rozdíl to má ale pro vývojáře – a nejen ty čtyři současné, ale i budoucí. Hlavní rozdíl se projeví při vývoji nějaké novinky. Na SVN se každým commitem tne do živého. A když se nějaká cesta ukáže být slepou, je potřeba commity vracet zpět. Programátor tak raději během vývoje nic nekomituje, verzování si řeší sám ručně a teprve až to má hotové a odladěné, a pak to tam pustí jako jeden obrovský commit. To je samozřejmě špatně.

Pokial viem, tak SVN rovnako branches a merges ovlada tiez. Pouzivam to bezne. Preto sa divim, ze toto davas ako hlavny dovod. Je nejaky problem s branching pri Subversion, ktory nie je pri Git/Mercurial ?

A proč se na ten Mercurial/Git nepřejde a nezrcadlí se to na SVN?

Jinak něják mě to taky nakoplo. A docela se mě to líbí (místo tří svnek na projekt bych měl jeden Mercurial/Git). Ta „lokální“ kopie je teda jenom u mě na PC nebo se nahraje na server? (Když se mě náhodou podělá disk tak jestli příjdu o data nebo ne).

PS: Blogneš pak něco jako How To Switch SVN to Git/Mercurial? (nemyslím přímo ten přechod ale náviky v používání).

Hmm, tak som sa na podnet tohto threadu tomu trosku dnes povenoval, a naozaj git/mercurial zrejme stoji za migraciu. Pre mna je dolezite, ze git velmi pekne spolupracuje so svn, co je pre mna dolezite, kedze v praci pracujeme prave so SVN a nejaky okamzity prechod neprichadza do uvahy. Takze viem pracovat lokalne s git-om a vyuzivat jeho naozaj elegantne branches/merges, commitovat a updatovat priamo do SVN repo a zaroven aj do git (ak by bolo potrebne).

Revize != commit. Může být x commitů s různými fixnutými chybami apod., označení jednotlivých komitů je to ošklivé sha1. A pak se udělá tag, třeba r475, které zahrnuje x komitů, ale revize poskočí o jedno čísílko. Musí se teda dělat manuálně, ale… :-)

Editoval jasir (4. 8. 2009 14:37)

sodae napsal(a):

Davide, z praktického hlediska pro vývojáře ano to je dobré ale z pohledu updaterů nejspíše zle (jak napsal PetrP), že jsem si již zvykli a lepší SVN jednočaré a lépe orientace v revizích (fórum,IM), aspoň si to neumím představit: „je bug v revizi p32147ffd54f (příklad)…“, tedy jsem pro zůstání u SVN. Ale kdyby bylo něco ve stylu recommit na SVN tedy že by všechny revize v tagu (jak popsal jasir) se nahrály na SVN vedlo by to ke spokojenosti, aspoň si to myslím.

edit: změna nicku , splet jsem si je

Podle toho, jak to popisuje jasir, tak nemáš úplně pravdu. Vývojáři budou dělat commity jak se jim zlíbí — ty, když budeš chtít, tak si můžeš sosat „bleeding edge trunk“, ale předpokládám, že David čas od času udělá tag, který pojmenuje právě např. r450 (do Changelogu napíše, že změny se projeví od tagu r450 a výše a pěkně je tam vypíše) — když najdeš chybu, můžeš hlásit, že je to commit s sha1 BLEBLE, nebo řekneš, že je to v tagu r450. Když o tom tady tak píšu, tak se mi ten postup líbí víc než přesné párování co commit to revize (což je evidentně to, co nejvíc vadí ;)), i když uznávám, že i to se dá v SVN dělat.

Jednoznačně chceme přejít na GIT!!!;-) – GIT je lepší! A Karmi má pravdu;-)…V Clevisu jsme už na GIT z SVNka přešli…a máme jen samé dobré zkušenosti…

Inza napsal(a):

Jednoznačně chceme přejít na GIT!!!;-) – GIT je lepší! A Karmi má pravdu;-)…V Clevisu jsme už na GIT z SVNka přešli…a máme jen samé dobré zkušenosti…

Nechceš blognout takové How to jak přejít ze SVN na Git/Mercurial pro „BFU“. Se samotným přechodem to asi nebude tak složité ale něják se motám v tom že SVN = centralizované a Git/Mercurial = decentralizované. Jinak řečeno vím co to znamená a jak to asi funguje ale nedokážu si představit jak na to. Neboli hodilo by se krok po kroku popsat jak dělat tohle co dělám běžně v SVNku na Git-u/Mercurial-u.

1. checkout-nu projekt
2. upravím něco a commitnu a hned mají všichni k dispozici novou revizi (vím že si v Git-u/Mercurial-u můžeš commitovat jenom u sebe a ven se to pak něják kopíruje nebo co. A to je právě to co nechápu…)
3. někdo něco upravil a tak update-nu
4. udělám další změnu a zase to chci pustit ven (commit-nu)

Prostě jsem nikde nenarazil na to aby to někdo „lajcky“ vysvětlil.

PS: nejsem dobrý angličtinář a tak by mě studování toho jak to funguje trvalo dlouho protože jsem nenarazil na český článek/návod/nápovědu jak na to. Předem díky.

jasir napsal(a):

Jakub Kulhan má sérii článků na www.programujte.cz. (Btw Jakub je i tady na fóru :-)

Super… Jsem u 6té kapitoly a jsem rozhodnut že ze SVN přecházím na Git/Mercurial teď se jenom rozhodnout který (Mercurial má výhodu že je na Google Code – v GitHub-u se zatím plácám).

Ale mám poslední otázku asi na Jakuba…
Hlavní důvod proč bych přecházel je následující. Niní mám projekt postavený na nette a dibi a brzo půjde ven (OSS) ale má se to tak (na SVNku). Mám repository u sebe na serveru neveřejnou (pracovní) kde mám celý projekt nějáké věci které nejsou zatím napsané dokonale ale fungují a sám je používám. A pak mám repository na Google Code kam budu dávat kód až bude učesaný a nebude obsahovat ty nedokonalé featury které mám v té neveřejné repository. Když bude nějáká novinka změna tak jí vyvýjím v té neveřejné repository a pak akorát zkopíruju a commitnu do veřejné (té na google code). A to je hlavní důvod proč bych přecházel na Git/Mercurial měl bych jenom jednu repository kde mám jak svoji pracovní větev (nazvu jí work) tak veřejnou (podle terminologie gitu Master) v jedné repository a akorát přesouvám změny. Ale pokud chci aby pracovní větev byla neveřejná tak commituju lokálně bez připojení na server a posílám na server akorát to co už je učesané/dokonalé. Jinak řečeno „work“ větev není na serveru ale jenom lokální (nebo tak jsem to pochopil – kdyžtak mě oprav). A teď jak na tohle mám notebook na kterém to celé je a příjdu ke kamarádovy/do práce a chci mít přístup k „work“ větvi ale nemám možnost se dostat na domácí notebook (nemám veřejnou IP). A tak chci mít na serveru i „work“ větev ale chci abych k ní mohl přistupovat jenom já. Jak na to? To je totiž hlavní důvod proč bych přecházel ze SVN. (Možná to v tom seriálu na Programujte.com je ale je těch informací na mě moc a musím si to něják porovnat v hlavě.

jakubkulhan napsal(a):

vrtak-cz napsal(a):
[ dlouhatánský text … ]

Sice jsem přeložil GitMagic, ovšem i tak se stále cítím spíš jako nováček, co se týče Gitu :-) Pokusím se odpovědět.

Ja si právě myslel že jsi Git „guru“ a proto jsi to překládal aby jsi pomohl rozšíření v ČR.

Jestli jsem to pochopil správně, šlo by o to mít dvě větve – master a work –, kde work by nebyla přístupná veřejnosti, ale tobě ano, a to odkudkoli?

Ano přesně tak…

Základem je nějaký server s pevnou IP adresou. A buďto je potřeba přístup přes SSH s možností spouštět vzdáleně git, nebo server musí podporovat WebDAV a pak se dá exportovat repozitář (jak pro git fetch, tak pro push) přes HTTP(S).

Tak server mám… Nebo máme GitHub a další…

Na GitHubu je možnost si za nějaký ten peníz zřídit privátní repozitář. Zatím jsem nepotřeboval, takže nevím, jak to tam přesně je – jestli by šla veřejnosti zpřístupnit jenom některá z větví.

O to mě přesně jde. Asi si tam o tom něco přečtu…

Ale určitě by šlo si vytvořit privátní a veřejný repozitář a pak si v lokálním klonu přidat oba jako remotes:

$ git remote add public git@github.com:vrtakcz/verejny
$ git remote add origin git@github.com:vrtakcz/privatni

Takže bych na tom byl podobně jako u SVNky… :-(

Udělal jsem změny v pracovní verzi a chci je promítnou na server:

$ git push origin work

To je jednodušší než to jak to řeším teď (teď musím export->pročistit co nechci pustit ven->prepsat soubory po update z public repository->commitnout)

Když jsi u kamaráda a chceš získat svou pracovní verzi (je nutné poznamenat, že bude potřeba narozdíl od centralizovaných VCS, provést předchozí operaci před každým odchodem z domu, jinak se ke změnám prostě nedostaneš, protože zůstávají do push u tebe na disku):

Jasny s tim se pocita… (asi bych si to hodil do cronu – jednou za hodinu by se to delalo samo).

Jinak díky za odpověď.

Editoval vrtak-cz (5. 8. 2009 15:47)

vrtak-cz napsal(a):

Ještě mě napadly dvě otázky jak číslovat revize? V GitMagic-u se píše že to jde něják scriptem ale jak?

Jde to např. pomocí post-receive hook na serveru – vždycky, když se pushne na server, zavolá se post-receive hook, která označí HEAD tagem s číslem revize (číslo poslední revize si musí někde udržovat). Je ale potřeba nějak ten skript na server dostat.

Pokud si Git hostuješ sám, jde to jednoduše. Pokud ti ho hostuje někdo jiný, může to být problém. Ale např. u GitHubu jde nastavit post-receive hook tak, že po úspěšném pushi propinkne nějakou adresu. Z té adresy na to můžeš zareagovat tak, že skrz GitHub API přidáš nový tag (tedy alespoň doufám, že to jde).

Přeci jenom když bude někdo psát že v revizi XYZ je chyba tak nebude posílat celý SHA1 hash když může poslat číslo…

Nemusí posílat celý SHA1 hash – pokud neexistuje žádný jiný objekt, jehož hash začíná stejně, stačí poslat první čtyři písmena. Že se pořád musí posílat celý hash je blud. Teď je v SVN Nette u pětistovky – 3 písmena. 3, nebo 4 – to už není takový rozdíl.

Nepřemýšlej o hashi jako o řetězci, ale jako hexadecimálním čísle ;-)

Ale je pravda, že pokud chci přesně identifikovat commit, je lepší poslat celý hash.

A další funguje v Git-u/Mercurial-u něco jako svn:keyword?

Git nic takového nemá, u Mercurialu nevím. Linus Torvalds se o této feature SVN vyjádřil následovně, takže podporu v nějaké nadcházející verzi bych nečekal. Není ani divu, když to, myslím, byl Linus, kdo Git vydal s tím, že je to stupid content tracker.

Celkově je podle mě potřeba na Git pohlížet ne jako na rychlejší SVN, ale jako na úplně jiný verzovací systém, protože tím opravdu je. Git sice můžeš využívat stylem SVN (co commit, to nová revize) a rovnou to všechno pushnout na server, ale taky nemusíš. Pro distribuované VCS jsou různé způsoby organizace commitů. Doporučuji si dále pročíst (spíš prohlédnout, vždyť jsou to jenom obrázky) prezentaci od Scotta Chacona (jednoho ze správců/provozovatelů GitHubu).

PetrP napsal(a):
To sice ano, ale dejme tomu že od a23b4 funguje to a to, a teď mi řekni když mám 2c689 bude mi to fungovat? ;]

$ git log --pretty=oneline 2c689 | grep a23b4

Vypíše-li to něco, commit máš, a tak by ti daná feature měla fungovat (pokud nějaký commit mezi tím, ve kterém byla přidána, a tom, který máš, opět nezničil).

Tak tak, často jsou například na fóru odkazy na googlecode na konkretní revizi a řádek, podle hashe naprosto nepoznam jak stará ta revize je, nebo jestli je aktualní, a to ani po tom co na ten odkaz vlezu. ;/

Pokud se jedná o GitHub, tak když odkážu na konkrétní řádek konkrétního souboru v konkrétním commitu, když tam vlezu, vidím v rámečku kdo a kdy commit provedl.

Chci-li zjisti, kolikrát byl soubor změněn od určitého commitu, řekněme abcd?

$ git log --pretty=oneline abcd..HEAD soubor.php | wc -l

Kdy naposledy byl soubor změněn a v jakém to bylo commitu:

$ git log --pretty="%h %ar" soubour.php | head -n 1

Poznámka: Jelikož Git umožňuje nelineární vývoj, přistupovat ke commitům podle čísla ztrácí smysl. Řekněme, že něco vyvíjíme něco ve větvi develop a usoudíme, že změny jsou dost stabilní na to, aby se dostali do master větve. Kdyby s každým commitem přibývalo číslo, mohli bychom v master mít commit s číslem 256 a najednou 512.

Další poznámka: Jelikož celá historie repozitáře je u tebe na disku, všechny tyhle operace jsou narozdíl od SVN neuvěřitelně rychlé.

Editoval jakubkulhan (5. 8. 2009 21:48)

jakubkulhan napsal(a):

$ git log --pretty=oneline 2c689 | grep a23b4

Vypíše-li to něco, commit máš, a tak by ti daná feature měla fungovat (pokud nějaký commit mezi tím, ve kterém byla přidána, a tom, který máš, opět nezničil).

Vizuální kontrole, takříkajíc na první pohled se to jaksi nevyrovná. A to ani v případě že si ten příkaz zapamatuju, a budu vědět kam ho napsat ;]

Nevím jestli to je mercurialem nebo google codem, ale má to více jak 4 znaky 9bffc87e37, to už je ale vcelku jedno.

Děkuju vám ale za reakce. Důležité je jestli se to bude dobře používat vývojařům, mi řadový uživatelé si už prostě zvyknem ;]

PetrP napsal(a):
Vizuální kontrole, takříkajíc na první pohled se to jaksi nevyrovná.

Jak psal jasir revize != commit (resp. může ale nemusí). Vývojář prostě udělá změnu sem, commit, změnu tam, commit, další změnu, commit atd. Udělá takhle třeba 10 commitů, HEAD označí tagem r512 a pushne změny na server a na revizi se můžeš opět odkazovat číslem – a máš to takříkajíc na první pohled.

Může se to zdát jako blbost, když SVNko ale tohle dělá rovnou, a tak to ušetří všem práci, né? Ale opravíš překlep sem, překlep tam a, jak tu někdo psal, je blbé kvůli tomu burcovat SVN server, tak k tomu přibalíš ještě něco většího a pak teprve uděláš teprve commit. U DVCS prostě commituješ, jak jdeš – překlep sem, oprava, commit, překlep tam, oprava, commit. A když si řekneš, že stav, který teď máš je dobrý, přidáš tag s číslem revize (řekněme že předchozí revize byla r499, tak teď přidáš tag r500) a pushneš na server. A děláš takový projekt jako je třeba Nette a chceš oznámit změny mezi revizemi? Tak si uděláš changelog:

$ git log --pretty="- %s" r499..r500

A to ani v případě že si ten příkaz zapamatuju, a budu vědět kam ho napsat ;]

Nemusíš si příkaz zapamatovat, stačí vědět, jakou mají Gití příkazy logiku a odvodíš si, co potřebuješ.

Předpokládám, že jsi Windowsář, jinak bys snad věděl, kam to zapsat :-) Něco o tom twítovali @dmajda a @hassmanm na Twitteru:

• http://twitter.com/…s/3102287948
• http://twitter.com/…s/3102323093
• http://twitter.com/…s/3103595708
• http://twitter.com/…s/3103631850

jakubkulhan napsal(a):

PetrP napsal(a):
Vizuální kontrole, takříkajíc na první pohled se to jaksi nevyrovná.

Jak psal jasir revize != commit (resp. může ale nemusí). Vývojář prostě udělá změnu sem, commit, změnu tam, commit, další změnu, commit atd. Udělá takhle třeba 10 commitů, HEAD označí tagem r512 a pushne změny na server a na revizi se můžeš opět odkazovat číslem – a máš to takříkajíc na první pohled.

Tady jde o to že my se na to pořád koukáme jako commit → verene dostupna, otestovana a sabilní verze. Myslíme číslovat revize které se dostali na server (Tzn když to hodně přeženu tak „SVN Commit“ = „Git push“ – pro nás).

Jod napsal(a):

Ako je to s integráciou gitu/mercurialu do IDE a editorov? Mňa to konkrétne zaujíma okolo systému Mac OS X, aj keď teraz nejake tú integrovanú podporu svn v editoroch nevyužívam. :D
Viem, že NetBeans má od verzie 6.7 integrovanú podporu kenai , ktorý poskytujé svn/mercurial/git . Celkom zaujímavá vec.
Predsalen by nebolo zlé mať všetko all-in-one, hlavne keď je niekedy človek liezť do command-line a písať tam haky baky :)

do eclipse jest mercurial plugin http://www.vectrace.com/…rialeclipse/

Pro hostovani Mercurial repozitare je mozne pouzit i BitBucket.

Vedle Github nebo BitBucket vypadá Google Code jako chudý příbuzný, ať už se přejde na Git nebo Mercurial, Google Code bych opustil.

Objektívne námietky nemam. Subjektívne, Github web je nejaký spomalený :/

Takže si mame inštalovať TortoiseGit :-D

A btw bude repozitár aj s verziou Nette pre PHP 5.3?

Teď mi poslal Johno link na Hg-Git mercurial plugin.

David Grudl napsal(a):

Takže: https://github.com/nette/nette

Jak se tedy budou řešit čísla revizí? Ty hashe vypadají dost strašně, jinak je ale github dobrá volba :)

Honza M. napsal(a):

Když mi někdo řekne, jak nahradit svn:externals, tak ne.

Mělo by to jít něco jako Git Submodule… Ale přesně nevím.

Já spíš momentálně řeším problém, jakým způsobem lze použít svn:externals v mých projektech tak, abych mohl fetchovat Nette přímo z gitu. Větší úspěch než ti předemnou ale bohužel nemám :]

Editoval Dragon Jake (14. 8. 2009 16:07)