No lol — co začalo jako přechod mezi SVN a Mercurial, skončilo jako přechod mezi SVN a GIT — škoda, že mě víc zaujal Mercurial…

Teď se dívám, že na http://github.com/…mmits/master si ty revize nějak číslují, zajímalo by mě jak.

To je sice zajímavý post, ale to ještě David nevěděl, jaká to bude mít všelijaká úskalí, takže jak to dopadne se ještě neví ;-) Ale ono to nějak dopadne…:-)

Problemy s rychlosti jsou u GitHubu celkem zname, ale zda se ze se nejak resi, viz treba http://support.github.com/…me-very-slow. Jinak dalsi repository hosting pro Git je napr. Gitourious.

Editoval Nilp (16. 8. 2009 9:51)

Jenom by me zajímalo jak vyřeší se verzovaní v dokumentaci (phpdoc).

/**
 * @version $Id$
 */

Právě kvůli tomuto problému jsem migroval projekty na Mercurial a ne na Git. Nechtělo se mi vracet se k ručnímu číslování. Linus má svůj názor k čemu RCS keywords a tak ani do budoucna se podpory v Gitu asi nedočkáme.

Veľké veci si žiadajú veľké obete :D

A nešel by napsat nějaký skript co by třeba přes exec vždy překopičil změny na SVN?

Nemám problém s tím, že je to na Gitu, jen ještě k tomu svn:externals — svn:externals se hodí, když projekt vyvýjí více lidí a někdo si dá tu práci, aby přes svn:externals nechal automaticky stahovat nějaký tag (verzi), se kterou zbytek aplikace v pohodě běží. Když jsem někde výše psal, že je škoda, že svn:externals není, neměl jsem na mysli, že nejde automaticky stahovat nejnovější verzi Nette, vadí mi, že teď, když přijde vývojář, tak musí stáhnout projekt, kde bude pracovat a pak ručně dostahovat správné verze Nette a Dibi ;). S svn:externals to šlo automatizovat na jeden svn checkout, který tomu člověkovi automaticky sosnul i správné verze Nette a Dibi — nicméně jak určitě někdo navrhne, i tohle se dá řešit jinak, podle mě by to mělo umět řešit nějak IDE už v rámci projektu (který si tak jako tak ten vývojář stejně musí stáhnout) — někde tam by mělo být napsáno, že projekt vyžaduje Nette a Dibi ve specifických verzích, které jdou nalézt na svých repozitářích — fakt ale nevím, jestli tohle nějaké samotné IDE řešit umí, troufal bych si říct, že by něco takového šlo řešit přes Maven, ale když jsem tuhle experimentoval s jeho podporou pro PHP, docela slušně jsem narazil :(.

Další, co mě docela zarazilo je následující: v repozitářích Nette i Dibi to je tak, že hned v kořeni je spousta věcí, které běžně vůbec nepotřebuju — extras, examples, 3rdParty, atd. — u svn jsem mohl checkoutovat např. nette.googlecode.com/svn/trunk/Nette a stáhlo se mi jen čisté Nette, bez příkladů apod. U Dibi je to to samé, tak jsem checkoutoval dibi.googlecode.com/svn/trunk/dibi a dostal jsem jen Dibi. Git tohle neumí (Nejspíš je to dáno tím, že metadata nejsou jako u Svn v celém stromu, ale jen v kořeni, který by se nestáhl, kdybych checkoutnul jen podadresář.), když nad tím ale přemýšlím, je otázka, jestli je vůbec dobře mít to takhle pohromadě v jednom repozitáři; vím, že ty věci spolu úzce souvisí (Nette příklady si bez samotného Nette pustím asi špatně.). Díky tomu, že vytvoření nového repozitáře „nic nestojí“ bych byl pro zvážení, jestli neudělat těch repozitářů víc — třeba jen Nette (kde budou fakt jen zrdojáky Nette) a Nette-additional (kde bude zbytek) — to stejné pro Dibi.

EDIT: Omlouvám se za dlouhý příspěvek :).

Editoval Petr Motejlek (19. 8. 2009 10:59)

romansklenar napsal(a):

Ještě Davide svn repozitář na google codu nezabíjej prosím :) pokud budeš při vývoji na gitu používat tagování nějakých větších releasů jako 0.9.1 atd, tak se nabízím k tomu, že budu importovat tyto releasy do SVN pod tagy alespoň pro stable verze a tím je situace s externals vyřešená.

V podstatě to tak dělám – komituju tam stable release s dovětkem, že repozitář se přesunul.

Chtěl jsem to tak dělat (už na SVN), ale nepodařilo se mi na serveru zprovoznit generování phpDoc.

Pro minified verzi samozřejmě potřeba není. Chtěl jsem na server přesunout kompletní generování distribučních balíčků včetně API dokumentace a spouštět je přes post notifikaci, ale tím, že jednu část musím stále generovat na svém komplu, to ztratilo na efektivitě.

Prednaška o gite.

GitCasts: RailsConf Git Talk

Je zajímavé si toto vlákno si přečíst po téměř 4 měsících pročítat. Myslím, že všechny obavy s používání Gitu padly, nezaznamenal jsem zde na fóru jediný problém. Git já osobně nyní používám už 8 měsíců a jsem navýsost spokojen. Docela hodně by mě zajímalo, kolik lidí tady z fóra se na základě (nejen) tohoto vlákna rozhodli přejít na Git a jak jsou spokojeni oni…

Já se v podstatě potýkám (dělam na Windows) jen s různými konci řádků CR/LF, které se někdy prostě rozhodnou chovat divně. Většinou to napravím pomocí config directivy autocrlf, ale nějak jsem asi nepochopil její význam, někdy tam musí být input, někdy true, někdy false :-), už jsem z toho volaký zmatený. Nevíte někdo jak tohle jednou provždy vyřešit?

Petr Motejlek napsal(a): Další, co mě docela zarazilo je následující: v repozitářích Nette i Dibi to je tak, že hned v kořeni je spousta věcí, které běžně vůbec nepotřebuju — extras, examples, 3rdParty, atd. — u svn jsem mohl checkoutovat např. nette.googlecode.com/svn/trunk/Nette a stáhlo se mi jen čisté Nette, bez příkladů apod.

a pak tento „pseudo“ problém. Sám ho řeším tak, že mám v hlavních adresářích nette,dibi soubor netterobots.txt zakazující přístup do examples apod. Myslím, že by to ani v distribuci ničemu neuškodilo.

Jinak co se týče nástrojů, TortoiseGit nyní prakticky využívám ke změně ikonek v systému, nejlépe se mi pracuje v příkazové řádce a git-nativním grafickém nástroji (tak 70% ku 30% pro shell).

A na závěr takový malý tip pro uživatele PhpEdu : hoďte si do gitu jeho configurační adresář.

Editoval jasir (21. 11. 2009 5:03)