Mergeinfo je verzovaná property svn:mergeinfo
, obsahuje historii merge operací nad daným adresářem nebo souborem.
Když má cesta nastavenou mergeinfo property tak o této cestě říkáme, že má explicitní mergeinfo. Cestou se myslí adresář nebo soubor.
Běžně je mergeinfo nastavené pouze na cíli merge operace. Subtree mergeinfo se objeví když:
Několik případů, kdy nedojde k vytvoření nebo změně mergeinfo:
--ignore-ancestry
Pokud cesta nemá explicitní mergeinfo používá mergeinfo svého rodiče/nadřazený adresář (nebo jeho prarodiče atd.) s explicitním mergeinfo. Koncept nejbližšího rodiče není omezen na pracovní kopii. Při zjišťování zděděného mergeinfo na cestě bez explicitního mergeinfo Subversion nejdříve prohlíží pracovní kopii směrem k jejímu kořenu. Pokud se dostane až ke kořenu pracovní kopie a stále nemůže najít explicitní mergeinfo, požádá repository o další prarodiče až ke kořeni celé repository. Pouze pokud nebyla nalezena žádná cesta s explicitním mergeinfo lze říci, že daná cesta nemá žádné (zděděné) mergeinfo. Pokud cesta dědí mergeinfo, dědí jen pouze z nejbližšího rodiče s explicitním mergeinfo.
Empty mergeinfo is a svn:mergeinfo
property which has the empty string as a value. It simply means the state of this path is as if nothing was ever merged into it.
Prázdné mergeinfo je svn:mergeinfo
property, která má prázdný řetezec jako svojí hodnotu. Tato hodnota znamená, že stav této testy je takový jako kdyby do ní nebylo nikdy nic zamergované.
Na konci každé merge operace se Subversion pokusí "konsolidovat" přebývající subtree mergeinfo. Po dokončení merge operace Subversion prochází pracovní kopii merge cíle. Když nalezne cestu s explicitním mergeinfo. která má subtree se stejným explicitním mergeinfo, tak toto subtree mergeinfo odstraní.
Předpokládejme, že pracujete na kódu ve větvi, která bylo zkopírovaná z trunku. Během vývoje se pravidelně provádí merge na všechny nové změny z trunku takže větev je vždy synchronizovaná s prací v trunku. Když nakonec větev zamergujete do trunku, je tato operace nazvána cyklickým merge. Cyklický merge má tyto problémy:
Subversion již umí řešit cyklicé mergování. Jde o stejný typ merge operace existující již před verzí 1.5 a říká se mu 2-URL merge (Reintegrace)
Je třeba zdůraznit, že jakmile je větev reintegrovaná zpět, měla by být smazána z repository. Pokud je potřeba provést další změny, je třeba větev znovu vytvořit z nové kopie. Jsou pro to dva důvody:
Nový přepínač reintegrate je zkratka pro 2-URL merge s bezpečnostní kontrolou. Kontrola ověřuje, zda pracovní kopie obsahuje pouze jednu revizi, nemá žádné přepnuté potomky a nejde o "řídký" checkout (t.j. hloubka pracovní kopie je nekonečno). Nejvíce kontroverzí kontrola při reintegraci je ověření, že merge zdroj neobsahuje žádné subtree mergeinfo. Bez těchto kontrol je 2-URL merge náchylný na chyby jako je použití špatného URL nebo špatného čísla revize. Více informací o reintegraci můžete nalézt na Subversion merge reintegrate, část Reintegrate to the Rescue
Zjistit mergeinfo na celém stromu, XML formát je vhodný pro lepší čitelnost výstupu:svn propget svn:mergeinfo --recursive --xml
Smazat mergeinfo na stromu kromě rootu (cíl merge operace)svn propdel --recursive svn:mergeinfo ./*
Subversion merge reintegrate
Subversion 1.5 Mergeinfo - Understanding the Internals
Komentáře
Reintegrace vice branchu
Dobry den, pekny clanek :-)
Mel bych dotaz k tematu, jelikoz se prave pokousime o zavedeni trung/branch vyvoje a narazili sme na problemy, kdy pri promitani zmen z trunku do branche pripadne zpet nam nastavaji problemy s konflikty prave v merge-info. Zajimave je ze nedoslo ke zmene souboru, ale prave pouze ke zmene merge-info a to bud pridani teto vlastnosti, zmena hodnoty a nebo odstraneni.
Nas cil je takovy, ze bude existovat trunk a x branchu ve kterych budou tymy programovat pozadovane zmeny jakmile bude zmena naprogramovana a pouzitelna, provedeme reintegraci. Posledni co nam v tomto pripade zbyva vyresit co s merge infem. Mame ho pravidelne v trunku promazavat?
Muze se totiz stat ze reintegrace branchu bude probihat dost nahodile. Napriklad tak, ze z trunku vznikne 5 branchu, ktere se samostatne po dokonceni reintegruji, mezi tim vznikne treba dalsi branch atp. Dale je take moznost ze z branche vznikne kratkodobe branch pro vyvoj nejake samostatne funkcionality.
Je vubec nas postup myslitelny a pokud ano, jak postupovat.
Dekuji mnohokrat za nakopnuti smerem k vysnenemu cily.
A.
Díky za podporu. V článku je
Díky za podporu. V článku je uvedeno v jakých případech vznikná merge-info mimo root trunku/branche. Subversion 1.6 je o trochu chytřejší, nicméně není to dokonalé. Merge-info v podstatě ničemu nevadí, ale bude se vám objevovat/množit v logu jako změna souboru, kterou, pokud vím, nelze ani ve verzi 1.6 odfiltrovat. Proto je tedy vhodné čas od času jej (samozřejmě mimo root) vymazat. Vše platí ze předpokladu, že vždy budete provádět merge na rootu trunku/branch. Pokud budete provádět merge na různých subtree, tak je naopak žádoucí merge-info nechat být.
Dekuji za odpoved, takze
Dekuji za odpoved, takze pokud (a to doufam, ze vsichni budou dodrzovat) se budou provadet merge pouze celeho trunku/branche/branche z brance :-) Tak staci nechat mergeinfo pouze na korenovem adresari? Tak to je super, hned to vyzkousim, nebyl sem si jisty, jestli mazat jenom v trunku, nebo jenom v branchi, nebo v obou. Zkusim to pravidelne promazavat po kazdem mergi a uvidime, snad se to casem dostane do optimalniho stavu i bez promazavani.
Jeste jednou mnohokrat dekuji.
A.