Přechod Subversion (SVN) → Git

Upozornění: Tohle vlákno je hodně staré a informace nemusí být platné pro současné Nette.
David Grudl
Nette Core | 7823
+
0
-

S myšlenkou opustit SVN mě nahlodal Karmi, velký propagátor Gitu. Rozdíl mezi SVN a Gitem je v tom, že SVN je centralizovaný repozitář, kdežto Git decentralizovaný. To má poměrně zásadní výhody pro vývojáře, popíšu později.

Pro Git existuje populární úložiště repozitářů github.com, které jsem jaxi nepochopil. Narozdíl od Google Code. Nicméně Google Code, kde je momentálně SVN repozitář Nette Frameworku hostován, nabízí nově i Mercurial, což je vlastně totéž jako Git (určitě to není totéž, ale z mého laického pohledu zatím jo). Doporučuju k nahlédnutí výbornou příručku.

V čem je Git/Mercurial lepší?

Z hlediska uživatelů, kteří se na vývoji nepodílejí a využívají SVN jen pro aktualizace, by přechod na Mercurial nic nezměnil. Tedy jen místo

svn checkout http://nette.googlecode.com/svn/trunk/

by použili

hg clone https://nette.googlecode.com/hg/

případně nahradili vymakané TortoiseSVN za mírně slabší TortoiseHg.

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ě.

Na Mercurialu si člověk může volně commitovat do svého repozitáře, kdykoliv, kdy si není jist dalším krokem, tak udělá novou větev a v ní to vyzkouší. Pokud je spokojen, sérii vzniklých commitů promítne do hlavní větve na Google Code. (podrobněji zde a tady)

Také je možné, aby commity na svém lokálním úložišti zpřístupnil někomu jinému, kdo má právo zápisu na Google Code, a ten je tam po schválení může přeposlat.

Zatím Mercurial jen zkoumám (na Texy), ale přejít na něj jsem čím dál tím víc rozhodnut, řeší totiž problémy, na které stále narážím.

Petr Motejlek
Člen | 293
+
0
-

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

jasir
Člen | 746
+
0
-

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 :-(

Edit: žádná hrůza, prostě mi k dvojici TortoiseSVN a TortoiseGit přibude ještě TortoiseHG :-)

Editoval jasir (3. 8. 2009 21:49)

romansklenar
Člen | 655
+
0
-

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

Petr Motejlek
Člen | 293
+
0
-

romansklenar napsal(a):

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

Našel jsem přes Google několik diskuzních vláken, ze kterých se mi podařilo vyčíst, že snad něco existovalo (existuje), ale stálo to za … Údajně se ta věc předělávala (předělává?), ale nic víc se mi nepodařilo zjistit.

David Grudl
Nette Core | 7823
+
0
-

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?

jasir
Člen | 746
+
0
-

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?

Nejsem expert a mercurial neznám. Ale používám git (windows) a šlape to výborně včetně klienta msysgit. Tam se mi líbí, že můžu komitovat (a nebo z komitu odebírat) i jednotlivé řádky (což TortoiseGit neumí). Branching je špica. A navíc je to od Linuse :-) Ale, jak jsem psal, mercurial neznám a je možné, že bude umět to samé. Čili – žádná křeč, uvidíme.

Velmi ale chválím přechod z SVN, já to právě udělal tak 2–3 měsíce zpátky a je to ohromná úleva – rychlost(!!!), přepínání, tvorba a merging jednotlivých branchů, paráda.
Jinak tady je takové srovnání různých VCS a tady je fakt simple návod s obrázkama a ukázkami použití v různých situacích.

Škoda že ti nevyhovuje ten github, já tak nějak myslel, že mu stačí předhodit svn repository a ono si to samo převede.

edke
Člen | 198
+
0
-

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 ?

Petr Motejlek
Člen | 293
+
0
-

edke napsal(a):

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 ?

Dost lidí zrovna merging SVN kritizuje, protože někdy je dost problém udělat merge, u kterého se nevyskytne žádný problém ;).

Patrik Votoček
Člen | 2221
+
0
-

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í).

Petr Motejlek
Člen | 293
+
0
-

Jestli tedy půjde alespoň po nějaký čas zrcadlit Mercurial do SVN (alespoň co se checkoutů týče), bude to super a asi nebudu mít námitky ;).

edke
Člen | 198
+
0
-

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).

PetrP
Člen | 587
+
0
-

Mě je to jinak uplně jedno, důležité je aby to vyhovovalo vývojařům (hlavně davidovi ;]) ale když jsem koukl na Texy tak mě uplně vyděsilo číslo revize e61be041c5 a v url dokonce e61be041c554fa7de11fce6bf47d3b3541e7a7e7

To bude dost sadomasochisticky psát že od revize d09175b1dc je nějaký BCbreak ;]

Editoval PetrP (4. 8. 2009 14:16)

jasir
Člen | 746
+
0
-

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
Nette Evangelist | 250
+
0
-

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

Editoval sodae (4. 8. 2009 22:25)

Petr Motejlek
Člen | 293
+
0
-

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.

jasir
Člen | 746
+
0
-

Jojo, je to tak. Ono právě tenhle přístup (a také rychlost GITu a možnost komitovat i jen jednotlivé řádky zdrojáku) vede k tomu, že těch komitů se dělá více a snadno se tak separují různé zásahy a úpravy kódu. V SVN když člověk opravil jen nějaký překlep v komentáři, nechtělo se mu dělat komit, to je pak taková trapná revize, že.

Další velmi pěkná vlastnost Gitu je, že repository je přímo v adresáři projektu (nikoliv nějaká centrální repository jako u SVN kdesi na disku) a je to jen jeden adresář v rootu projektu (ne jako SVN, které má v každém adresáři svoje data). No a úplně super je, že poslední revize v branchi se dá snadno upravit (přidat/odebrat změny, změnit popis).

GIT a SVN snadno koexistují v jednom adresáři/projektu – stačí jen v SVN nastavit vynechávání adresáře .git a v Gitu naopak adresářů .svn. Git tak třeba používám na lokální úpravy Nette (je jich jen pár, týkají se debugu apod.). Mám tedy adresář, kam normálně pomocí SVN stahuji Nette a současně tam mám GIT, kde udržuji vlastní verzi Nette v branchi MyNette. Normálně pracuji s MyNette, a když updatuji, přepnu na master, aktualizuji z SVN, komitnu změny do master, přepnu na MyNette a sloučím master do branche MyNette.

Editoval jasir (4. 8. 2009 23:38)

Inza
Člen | 330
+
0
-

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…

Cifro
Člen | 245
+
0
-

Sprostý som jak kýbel gitu,
ešte aj ten kýbel gitu má maturitu.

Taký malý off topic. Nemôžem si pomocť ale keď sa spomenie git tak mi príde na myseľ táto pesnička :-D

http://www.youtube.com/watch?…

Patrik Votoček
Člen | 2221
+
0
-

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
Člen | 746
+
0
-

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

Patrik Votoček
Člen | 2221
+
0
-

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
Člen | 55
+
0
-

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.

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? 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).

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í. 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

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

$ git push origin work

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):

$ git clone git@github.com:vrtakcz/privatni

Zpřístupnění veřejných změn světu:

$ git push public master

atp.

Pokud by stačilo mít větev work, když si někde pryč, pouze pro čtení (tzn. že bys nemohl provádět push /to by se zařídilo jinak/), měl by stačit nějaký z těch nejlevnějších hostingů. Nejdříve:

$ git update-server-info

Poté nahraješ obsah podadresáře .git někam na FTP – aby to bylo přístupné přes HTTP –, přidáš .htacces a .htpasswd a je to. Pak naklonuješ repozitář skrz HTTP:

$ git clone http://mujserver.cz/projekt.git

A když se vrátíš domů, tak můžeš změny pushnout např. po LANce, nebo si můžeš přímo u kamaráda vytvořit bundle (viz man git-bundle) a poslat si ji e-mailem… Fantazii se meze nekladou :-)

Patrik Votoček
Člen | 2221
+
0
-

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)

Patrik Votoček
Člen | 2221
+
0
-

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? 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… A další funguje v Git-u/Mercurial-u něco jako svn:keyword?

jakubkulhan
Člen | 55
+
0
-

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
Člen | 587
+
0
-

jakubkulhan napsal(a):

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.

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? ;]

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

Tak tak, často jsou například na fóru odkazi 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. ;/

jakubkulhan
Člen | 55
+
0
-

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)

jasir
Člen | 746
+
0
-

Petr Motejlek napsal(a):

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

Asi to půjde pomocí submodulů, viz tady video (tedy v případě git/githubu)

Editoval jasir (5. 8. 2009 21:57)

PetrP
Člen | 587
+
0
-

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 ;]

Honza Kuchař
Člen | 1661
+
0
-

Existuje nějaký GIT server pod Windows? Pokud možno i s GUI. Ideálně něco na styl VisualSVN. Protože opravdu nemám zájem se týden drbat s konfigurací GIT serveru.

jakubkulhan
Člen | 55
+
0
-

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:

Jod
Člen | 701
+
0
-

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 :)

Editoval Jod (6. 8. 2009 10:19)

Patrik Votoček
Člen | 2221
+
0
-

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).

jakubkulhan
Člen | 55
+
0
-

honzakuchar napsal(a):

Existuje nějaký GIT server pod Windows? Pokud možno i s GUI. Ideálně něco na styl VisualSVN. Protože opravdu nemám zájem se týden drbat s konfigurací GIT serveru.

Git žádný speciální server nepotřebuje – export repozitáře se provádí různé protokoly – pro fetch to jsou hlavně GIT protokol, HTTP(S), SSH; a pro push SSH, vzácně HTTP(S). A samozřejmě je tu ještě možno provádět export pro cokoli pouze přes systém souborů.

Doma žádný server nepotřebuješ – všechno máš na disku v jednom repozitáři alias (adresáři) – celou historii projektu, všechny soubory tagy, commity i stromy. Ve firmě je asi nejlepší mít Git na intranetovém serveru a přistupovat k němu skrz SSH. A pokud vyvýjíš něco pro „širší publikum“ (alias celý svět), jsou tu Git hostingy jako GitHub, repo.or.cz a třebas ještě Gitorious.

vrtak-cz napsal(a):

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).

V pojmech bude asi trochu zmatek. Ani jsi to moc nepřehnal, svn commit je vlastně jako git commit (třebas několik) společně s git push. Asi nejdůležitější ale, že svn commit != git commit.

Editoval jakubkulhan (6. 8. 2009 16:51)

FOUS
Člen | 15
+
0
-

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/

Jod
Člen | 701
+
0
-

fuj eclipse :)))

Nilp
Člen | 65
+
0
-

Pro hostovani Mercurial repozitare je mozne pouzit i BitBucket.

David Grudl
Nette Core | 7823
+
0
-

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

David Grudl
Nette Core | 7823
+
0
-

Mercurial je mi sympatičtější.

…viděl bych to tak, že Nette Framework přejde na GIT a Github. Jsou nějaké námitky? ;)

Cifro
Člen | 245
+
0
-

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?

Honza Marek
Člen | 1664
+
0
-

David Grudl napsal(a):
Jsou nějaké námitky? ;)

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

David Grudl
Nette Core | 7823
+
0
-

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

Ondřej Mirtes
Člen | 1536
+
0
-

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 :)

edke
Člen | 198
+
0
-

David Grudl wrote:

Mercurial je mi sympatičtější.

…viděl bych to tak, že Nette Framework přejde na GIT a Github. Jsou nějaké námitky? ;)

Ja som velmi spokojny :) Po vytvoreni tohto vlakna si ma nahlodal a sam som zacal mercurial a git skusat. Po dvoch dnoch som si vybral git a odvtedy nase firemne SVN pouzivam cez git-svn :) Takze s predstihom par dni som sa trafil do tvojej volby, co je pozitivne :)

Patrik Votoček
Člen | 2221
+
0
-

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.

johno
Člen | 10
+
0
-

LastHunter napsal(a):

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 :)

Osobne to ako problem nevidim, tak ci onak by sa mali vacsie verzie tagovat (napr. v0.8.3) a tam to bude jasne inkrementalne. Inak ci uz git alebo mercurial. Gratulujem k prechodu. V PHP komunite je to nezvycajny jav.

Editoval johno (14. 8. 2009 8:44)

Dragon Jake
Člen | 20
+
0
-

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)