Git a Subversion

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.