V tomto článku si řekneme, co jsou v SVN branches (větve), k čemu jsou a jak je inteligentně používat, aby byly ku prospěchu. Text předpokládá základní znalost SVN a pojmů jako je Repository, commit, update.
Je užitečný i
pro lidi, kteří už někdy s větvemi pracovali, zvlášť, pokud narazili na
nějaký problém. Ukazuje, jak je používat, aby nám byly ku prospěchu a
nepřidělávaly víc problémů neý kolik jich řeší.
Nebudu samozřejmně tvrdit, že následující popis představuje jediný způsob, jak větve v SVN používat, ale rozhodně je potřeba zacházet s nimi s vědomím toho, co děláme.
Napřed tedy o co vlastně jde: Větve v SVN představují nástroj, jak udržovat více variant jednoho projektu. Nemyslí se tím základní vlastnost SVN udržovat pomocí revizí záznam o každé změně. Se vznikem branch vznikne nová kopie projektu, kterou pak lze upravovat nezávisle na hlavní větvi.
Ukážeme si zde dvě různá použití a to formou praktické ukázky včetně toho, kam kliknout a co kam napsat v programu TortoiseSVN.
Na konci textu najdete shrnutí pomocí schématického obrázku a pomocí několika stručných tipů.
Napřed ilustrační obrázek:
Pracujeme s projektem, který má pracovní
jméno Kalkul a jde o systém evidence zvířat v zoo. Řekněme, že máme
programátora, který je zodpovědný za vývoj jedné komponenty pro tento
systém.
První verze komponenty, kterou vytvořil
vypadala takto:
Možná někdo zaznamenal, že v kódu je chybka - programátorovi se zaseklo "J." On, ani žádný jeho kolega si jí ovšem dlouho nevšiml, takže si jí zatím nebudeme všímat ani my a časem uvidíme, jak si s ní poradí.
Programátor samozřejmě třídu commitnul, což byla zcela běžná operace, při které nic jako branch nepotřeboval, ale pro připomenutí:
Po tomto commitu se třída začala
využívat v aplikaci a nějakou dobu byli všichni spokojení
Branch můžeme
použít v situaci, kdy plníme nějaký dlouhodobější úkol,
u kterého bychom rádi použili SVN i pro zálohování mezivýsledků
a přitom nechceme, aby se dočasná podoba naší práce projevila
ve společném úložišti. Po dokončení úkolu všechny změny reintegrujeme
do trunku a branch nebude potřeba dále používat. Operaci, kdy změny
provedené v jedné větvi přenášíme do trunku (nebo naopak, popřípadě
mezi větvemi) nazýváme merge.
Náš programátor, se tedy jednou rozhodl, že funkcionalitu komponenty rozšíří.
Napřed vytvořil novou větev:
Pravým tlačítkem kliknul na adresář s pracovní kopií trunku. (Dělá to jen proto, aby TertoiseSVN věděl, s jakým repozitářem se bude pracovat. Obsah lokálního disku se k ničemu nepoužije, veškeré změny proběhnou na serveru). Vybere příkaz Branch/tag.
Nejjednoduší způsob pro výběr umístění
nové větve je využít repo -
browser (otevření kliknutím na zvýrazněnou ikonku). SVN vám dovolí
téměř cokoliv, ale držte se zásady, že branch patří do adresáře
branches. Dočasné větve je zvykem pojmenovávat způsobem, který indikuje
jejich účel.
Všimněte si zakroužkovaných nastavení -
rozhodně nedávejte přepnout working copy do nové branch. Pro zachování
duševního zdraví je dobré držet se zásady, že každý lokální adresář
jednoznačně odpovídá něčemu v repository a to se nemění. Vzhledem k
tomu, že tato větev je určena k tomu, aby všechny změny z ní jednou
byly integrovány zpět do trunku, nemá smysl využívat jako základ větve
cokoliv jiného, než HEAD revizi z trunku.
Vytvořil si adresář, kde budou umístěny
větve pro tento projekt a do něj provedl checkout nově vytvořené větve:
Adresář je dobré pojmenovat nějak
mnemotechnicky.
Otevřel soubor Zvire.cs ze správné branch a provedl první změnu, se kterou mohl rovnou provést commit, i když nechala komponentu v nekonzistentním stavu:
Později komponentu dokončil a opět provedl ve větvi commit:
Protože má hotovo, může začít s operací merge. První krok (není na screenshotu) je update trunk na nejnovější verzi.
Poté zadal příkaz merge:
Protože provádí merge do trunku, zadá příkaz nad pracovní kopií trunku a tentokrát bude s touto kopií pracovat u sebe na disku.
Spustí se následující průvodce:
Vybere "range of revisions."
Následuje obrazovka průvodce s nejdůležitějšími nastaveními:
Zde zvolí branch, ze které provádí merge (může zase použít repo - browser) a nastaví, že chce všechno, co tam změnil.
Na poslední obrazovce je nejlepší nechat všechna nastavení tak jak jsou:
Provedením merge se změnil obsah adresáře s trunkem:
Tyto změny se ale zatím nijak neprojevily na serveru. Ale to není žádný problém, programátor prostě provede commit, stejně jako kdyby ke změnám došlo jakýmkoliv jiným způsobem:
Všechny změny, které programátor provedl v rámci větve a pak si je vytáhl do pracovní kopie trunku se nahrají v rámci jedné operace commit.
Hotovo.
Druhá situace kdy použijeme branch nastane, když chceme vytvořit novou verzi projektu, ke které se můžu chovat specifickým způsobem i když vývoj v trunku postupuje dál. Typické využití je, že firma v nějaké fázi vydá pojmenovanou verzi produktu, která je stabilní z hlediska poskytovaných vlastností. V SVN vytvoří branch, která jasně definuje, jak tato verze vypadá. Pro commit do takové větve pak existují jasně stanovená pravidla (např. jenom opravovat chyby, přidávat jenom explicitně vybrané nové vlastnosti, schválení release managerem apod.) - ta závisí na politice firmy.
Pokud nad větví probíhá nějaký vývoj,
často platí, že chceme provádět stejné úpravy nad ní i nad trunkem.
Opět můžeme používat merge.
Práce s trvalou větví vypadá technicky skoro stejně jak jsme si již ukázali, takže budu při popisu trochu stručnější.
Když se firma rozhodla vydat novou verzi
softwaru náš programátor byl pověřen vytvořením nové větve. V průvodci
pro novou branch vypadala Obrazovka s nastavením větve takto:
Branch slouží ke správě nezávislých verzí projektu, které si mohou žít vlastním životem.
Pokud nechci, aby si žily úplně vlastním životem, můžu mezi různými větvemi a trunkem provádět merge.
Větve typicky slouží jednomu ze dvou účelů:
Buď jako dočasná kopie projektu proti které provádíme nový vývoj, jehož výsledek pak integrujeme zpět do trunku,
nebo jako trvalá varianta, která jasně definuje „verze X našeho produktu vypadá takto“. Jak přesně s touto variantou pracujeme (jenom oprava chyb, drobné úpravy, dlouhodobější vývoj) závisí na firemní politice.
Praktický tip 1: Vždy mějte naprosto jasno s čím na serveru je spárována která pracovní kopie na vašem disku a zahrňte tento údaj do názvů adresářů. Nikdy nevyužívejte možnost „switch“ pracovní kopie.
Připomenutí: Při provádění merge jednorázově namíříte svou pracovní kopii proti jiné větvi, než kam míří normálně, a nahrajete do ní jasně specifikované úpravy. (Pak ještě musíte provést commit).
Praktický tip 2: Vždy vytvářejte novou branch jako kopii něčeho (typicky trunku) na serveru. Pokud vytvoříte branch nahráním své pracovní kopie, máte na serveru změny, jejichž vznik není nijak podchycen.
Praktický tip 3: Pokud delší dobu pracujete v krátkodobé větvi, pravidelně provádějte merge z trunku. Jde o nejspolehlivější způsob, jak se včas dozvědět, jestli vaše úpravy nebudou s něčím kolidovat až se budete snažit o merge ze své větve do trunku. (Tím nechci říct, že byste neměli dbát na kvalitní projektové řízení a komunikaci v týmu).