Ve světe open source software existuje několik skupin lidí – autoři, uživatelé a také správci balíčků a nezávislí vývojáři. Úkolem správců balíčků je ze zdrojového archívu udělat balíček, který splňuje požadavky dané distribuce a případně i opravuje chyby. Při řešení chyb je více než vhodné spolupracovat s autorem nebo autory daného programu. Za nezávislým vývojářem si můžeme představit člověka, který se při výskytu chyby v programu snaží chybu opravit nebo samostatně vyvíjí nové funkce. Těmto dvěma skupinám dává Git možnost mít u sebe celou kompletní historii projektu a snadné vytváření větví pak ulehčuje tvorbu oprav i práci na nových vlastnostech. A utilita git-svn umožní využití výhod Gitu i pro práci na projektech, které používají pro správu verzí systém Subversion.
Původně byl git-svn navržen jako nástroj pro obousměrné předávání sad změn mezi Gitem a Subversion pracující s jednou svn větví, ale vyvinul se do podoby, kdy je možné sledovat i modifikovat celou strukturu subversion repozitáře. Od toho se také odvíjí 2 scénáře, jak git-svn pužívat.
Začneme tím jednodušším, a to je sledování jedné větve Subversion
git svn clone svn://svn.danny.cz/libsql/trunk
čímž získáme kompletní historii větve trunk jako repozitář Gitu na lokálním počítači, větev trunk je možné nahradit za libovolnou jinou. A protože se přenáší celá historie dané větve, bude stahování nějakou dobu trvat. Strukturu lokální kopie nám ukáže
git branch -a * master git-svn
kde master je lokální větev a git-svn je vzdálená, napojená na svn repozitář. Pokud potřebujeme aktualizovat naši kopii, spustíme příkaz
git svn rebase
, který získá aktualizace ze vzdáleného repozitáře a zároveň je aplikuje do pracovních souborů.
Teď už můžeme s repozitářem pracovat, jako když máme normální klon, kde je na druhé straně také Git. Časem ale vznikne potřeba odeslat naše lokální commity do vzdáleného svn repozitáře, a tak použijeme
git svn dcommit
Druhou a efektnější možností je sledování celého svn repozitáře a použijeme nedávno v Softwarové sklizni přestavený Misfit Model 3D
git svn clone --stdlayout http://svn.misfitcode.com/misfitcode/mm3d
, kde přepínač –stdlayout zařídí rozpoznání svn větví a tagů. Nyní je nutné obrnit se trpělivostí ještě více než v předchozím příkladě, protože se stahuje svn repozitář včetně kompletní historie a svn protokol není v tomto případě moc efektivní.
Nyní se můžeme podívat jak vypadá struktura
git branch -a * master mm3d-qt4 tags/mm3d-1.3.6 tags/mm3d-1.3.7 tags/mm3d-qt3-1.3.7 trunk
, kde všechny větve kromě master jsou vzdálené.
Protože se ukázalo, že mm3d 1.3.7 nejde sestavit ve vývojové verzi Fedory, uděláme si lokální větev, kam budeme ukládat potřebné patche.
git checkout -b mm3d-1.3.7-fedora tags/mm3d-1.3.7
nyní se podíváme, co se změnilo
git branch -a master * mm3d-1.3.7-fedora mm3d-qt4 tags/mm3d-1.3.6 tags/mm3d-1.3.7 tags/mm3d-qt3-1.3.7 trunk
Pro aktualizaci naší kopie z svn použijeme příkaz
git svn fetch
, což je ekvivalent příkazu „git fetch“, který aktualizuje všechny větve v lokálním repozitáři, ale nezasahuje do pracovních souborů. Pro jejich aktualizaci pak můžeme použít
git rebase tags/mm3d-1.3.7 mm3d-1.3.7-fedora
Následovat bude „nezáživná“ práce na úpravě kódu, commit do lokálního repozitáře a pak vygenerování záplaty, kterou pošleme autorovi. A nebo, pokud máme právo zápisu do svn repozitáře, použijeme „git svn dcommit“.
Cílem tohoto článku nebyl detailní rozbor možností, které git-svn nabízí, k tomu lépe poslouží manuálová stránka a případně další dokumentace dostupná na webu, ale spíše ukázání postupů, které může použít správce balíčků nebo vývojář ve své každodenní práci. Za výhodu považuji i to, že svn repozitář se stáhne do přesně vymezených větví v lokální kopii, a tak nic nebrání v práci s lokálním git repozitářem používat své zaběhnuté postupy.
