Kontrola verzí - Version control

V softwarovém inženýrství , správu verzí (také známý jako kontrola revize , řízení zdrojů či řízení zdrojového kódu ) je třída systémů odpovědných za řízení změn počítačových programů , dokumentů velkých webových stránek nebo jiných sbírek informací. Správa verzí je součástí správy konfigurace softwaru .

Změny jsou obvykle označeny číselným nebo písmenným kódem, nazývaným „číslo revize“, „úroveň revize“ nebo jednoduše „revize“. Počáteční sada souborů je například „revize 1“. Když je provedena první změna, výsledná sada je „revize 2“ atd. Každá revize je spojena s časovým razítkem a osobou, která změnu provádí. Revize lze porovnávat, obnovovat a u některých typů souborů slučovat.

Potřeba logického způsobu organizace a kontroly revizí existuje téměř tak dlouho, jak existuje psaní , ale kontrola revizí se stala mnohem důležitější a komplikovanější, když začala éra výpočetní techniky. Číslování edic knih a revizí specifikací jsou příklady, které se datují do éry pouze pro tisk. Dnes jsou nejschopnějšími (a také komplexními) systémy pro řízení revizí ty, které se používají při vývoji softwaru , kde tým lidí může souběžně provádět změny stejných souborů.

Systémy pro správu verzí ( VCS ) se nejčastěji používají jako samostatné aplikace, ale kontrola revizí je také integrována do různých typů softwaru, jako jsou textové procesory a tabulky , kolaborativní webové dokumenty a do různých systémů pro správu obsahu , např . Historie stránek Wikipedie . Kontrola revizí umožňuje možnost vrátit dokument k předchozí revizi, což je zásadní pro to, aby editoři mohli navzájem sledovat úpravy, opravovat chyby a bránit se proti vandalismu a spamování ve wiki .

Přehled

V počítačovém softwarovém inženýrství je kontrola revizí jakýmkoli druhem praxe, která sleduje a poskytuje kontrolu nad změnami zdrojového kódu . Vývojáři softwaru někdy používají software pro řízení revizí k udržování dokumentace a konfiguračních souborů i zdrojového kódu.

Jak týmy navrhují, vyvíjejí a nasazují software, je běžné, že je na různých webech nasazeno více verzí stejného softwaru a že vývojáři softwaru pracují současně na aktualizacích. Chyby nebo funkce softwaru se často vyskytují pouze v určitých verzích (kvůli opravě některých problémů a zavádění dalších při vývoji programu). Proto je pro účely lokalizace a opravy chyb životně důležité, aby bylo možné načíst a spustit různé verze softwaru a určit, ve kterých verzích se problém vyskytuje. Může být také nutné vyvíjet dvě verze softwaru souběžně: například tam, kde jedna verze má opravené chyby, ale žádné nové funkce ( větev ), zatímco druhá verze je místo, kde se pracuje na nových funkcích ( kufr ).

Na nejjednodušší úrovni mohli vývojáři jednoduše ponechat více kopií různých verzí programu a vhodně je označit. Tento jednoduchý přístup byl použit v mnoha velkých softwarových projektech. I když tato metoda může fungovat, je neefektivní, protože je třeba udržovat mnoho téměř identických kopií programu. To vyžaduje hodně sebekázně vývojářů a často to vede k chybám. Vzhledem k tomu, že základ kódu je stejný, vyžaduje také udělení oprávnění ke čtení, zápisu a spuštění sadě vývojářů, což zvyšuje tlak někoho, kdo spravuje oprávnění, aby nebyla ohrožena základna kódu, což zvyšuje složitost. V důsledku toho byly vyvinuty systémy pro automatizaci některých nebo všech procesů kontroly revizí. Tím je zajištěno, že většina kroků správy verzí je skryta v zákulisí.

Navíc ve vývoji softwaru, právní a obchodní praxi a dalších prostředích je stále běžnější, že jeden dokument nebo úryvek kódu upravuje tým, jehož členové mohou být geograficky rozptýleni a mohou sledovat různé a dokonce i protichůdné zájmy. Sofistikovaná kontrola revizí, která sleduje a odpovídá za vlastnictví změn dokumentů a kódu, může být v takových situacích velmi užitečná nebo dokonce nezbytná.

Řízení revizí může také sledovat změny konfiguračních souborů , jako jsou ty, které jsou obvykle uloženy v systémech Unix /etcnebo /usr/local/etcna nich. To dává správcům systému další způsob, jak snadno sledovat provedené změny, a způsob, jak se v případě potřeby vrátit k předchozím verzím.

Dějiny

Nástroj pro aktualizaci softwaru OS/360 IEBUPDTE společnosti IBM pochází z roku 1962, pravděpodobně předchůdce nástrojů VCS. Plný systém určený pro řízení zdrojového kódu byl spuštěn v roce 1972, SCCS pro stejný systém (OS/360). Úvod SCCS, který byl publikován 4. prosince 1975, historicky naznačoval, že to byl první systém záměrné kontroly revizí. RCS následoval hned poté, se svou síťovou verzí CVS. Další generaci po CVS dominovala Subversion , následovaný vzestupem distribuovaných nástrojů pro kontrolu revizí , jako je Git .

Struktura

Řízení revizí spravuje změny v sadě dat v průběhu času. Tyto změny mohou být strukturovány různými způsoby.

Data jsou často považována za soubor mnoha jednotlivých položek, jako jsou soubory nebo dokumenty, a sledují se změny jednotlivých souborů. To je v souladu s intuicí o samostatných souborech, ale způsobuje to problémy při změnách identity, například při přejmenovávání, rozdělování nebo slučování souborů. Proto některé systémy, jako je Git , místo toho zvažují změny dat jako celku, což je pro jednoduché změny méně intuitivní, ale zjednodušuje složitější změny.

Když jsou data, která jsou pod kontrolou revizí, upravena, poté, co byla získána pokladnou, se to obecně neodráží okamžitě v systému kontroly revizí (v úložišti ), ale musí být místo toho zaškrtnuto nebo potvrzeno . Kopie mimo kontrolu revize je známá jako „pracovní kopie“. Jako jednoduchý příklad, při úpravách počítačového souboru, jsou data uložená v paměti editačním programem pracovní kopií, která je potvrzena uložením. Konkrétně je možné vytisknout dokument, ručně jej upravit a až později ručně zadat změny do počítače a uložit ho. Pro řízení zdrojového kódu je pracovní kopie místo toho kopií všech souborů v konkrétní revizi, obvykle uložená lokálně na počítači vývojáře; v tomto případě uložení souboru změní pouze pracovní kopii a kontrola do úložiště je samostatným krokem.

Pokud na jedné datové sadě nebo dokumentu pracuje více lidí, implicitně vytvářejí větve dat (ve svých pracovních kopiích), a proto vznikají problémy sloučení, jak je uvedeno níže. U jednoduchých společných úprav dokumentů tomu lze zabránit zamykáním souborů nebo jednoduše vyhýbáním se práci na stejném dokumentu, na kterém pracuje někdo jiný.

Řídicí systémy revizí jsou často centralizované, s jediným autoritativním úložištěm dat, úložištěm a check-outy a check-iny prováděné s odkazem na toto centrální úložiště. Alternativně v řízení distribuovaných revizí není autoritativní žádné jediné úložiště a data lze rezervovat a zapsat do jakéhokoli úložiště. Při kontrole do jiného úložiště je to interpretováno jako sloučení nebo oprava.

Struktura grafu

Příklad grafu historie projektu kontrolovaného revizí; kmen je zelený, větve žluté a graf není strom kvůli přítomnosti sloučení (červené šipky).

Pokud jde o teorii grafů , revize jsou obecně považovány za vývojovou linii ( kmen ), z níž se větví, tvořící směrovaný strom, vizualizovaný jako jedna nebo více paralelních vývojových linií („hlavní linie“ větví) větvení z kufru. Ve skutečnosti je struktura složitější a tvoří směrovaný acyklický graf , ale pro mnoho účelů je „strom se sloučení“ adekvátní aproximací.

Revize probíhají postupně v čase, a proto mohou být uspořádány v pořadí, buď podle čísla revize nebo časového razítka. Revize jsou založeny na minulých revizích, i když je možné do značné míry nebo úplně nahradit dřívější revizi, například „odstranit veškerý stávající text, vložit nový text“. V nejjednodušším případě, bez větvení nebo zrušení, je každá revize založena pouze na jejím bezprostředním předchůdci a tvoří jednoduchou linii s jedinou nejnovější verzí, „HEAD“ revizí nebo tipem . V teorii grafů , kreslení každé revize jako bodu a každého vztahu „odvozené revize“ jako šipky (konvenčně ukazuje ze staršího na novější, stejným směrem jako čas), je to lineární graf . Pokud existuje větvení, takže více budoucích revizí je založeno na minulé revizi nebo na vrácení, takže revize může záviset na revizi starší než její bezprostřední předchůdce, pak je výsledný graf místo toho směrovaný strom (každý uzel může mít více než jednu dítě) a má několik tipů, které odpovídají revizím bez dětí („nejnovější revize na každé větvi“). V zásadě nemusí mít výsledný strom preferovaný tip („hlavní“ nejnovější revize) - jen různé různé revize - ale v praxi je jeden tip obecně označen jako HEAD. Když je nová revize založena na HEAD, je buď identifikována jako nová HEAD, nebo je považována za novou větev. Seznam revizí od začátku do HEAD (v teorii grafů, jedinečná cesta ve stromu, která tvoří lineární graf jako dříve) je kmen nebo hlavní řada. Naopak, když se za účelem revize založeny na více než jedné předchozí kontroly (kdy uzel může mít více než jeden rodič ), výsledný proces se nazývá sloučení , a je jednou z nejsložitějších aspektů kontroly revize. K tomu nejčastěji dochází, když dojde ke změnám ve více větvích (nejčastěji ve dvou, ale je jich možné i více), které jsou poté sloučeny do jedné větve zahrnující obě změny. Pokud se tyto změny překrývají, může být obtížné nebo nemožné je sloučit a vyžadovat ruční zásah nebo přepsání.

V případě sloučení výsledný graf již není stromem, protože uzly mohou mít více rodičů, ale je místo toho zakořeněným směrovaným acyklickým grafem (DAG). Graf je acyklický, protože rodiče jsou vždy zpět v čase, a mají kořeny, protože existuje nejstarší verze. Za předpokladu, že existuje kmen, lze sloučení z větví považovat za „externí“ ke stromu - změny ve větvi jsou zabaleny jako oprava, která se aplikuje na HEAD (kmene), čímž se vytvoří nová revize bez jakéhokoli výslovného odkazu na větev a zachování stromové struktury. I když tedy skutečné vztahy mezi verzemi tvoří DAG, lze to považovat za strom plus sloučení a samotný kmen je čára.

V distribuované kontrole revizí mohou být za přítomnosti více úložišť založeny na jedné původní verzi (kořen stromu), ale nemusí existovat původní kořen, a tedy pouze samostatný kořen (nejstarší revize) pro každé úložiště například pokud dva lidé začínají pracovat na projektu samostatně. Podobně v přítomnosti více datových sad (více projektů), které si vyměňují data nebo slučují, neexistuje jediný kořen, i když pro jednoduchost lze jeden projekt považovat za primární a druhý za sekundární, sloučený do prvního s nebo bez vlastní historii revizí.

Specializované strategie

Kontrola technických revizí vyvinutá z formalizovaných procesů založených na sledování revizí raných plánů nebo bluelines . Tento systém řízení implicitně umožňoval návrat do dřívějšího stavu návrhu, v případech, kdy bylo při vývoji návrhu dosaženo technické slepé uličky. Ke sledování provedených změn byla použita tabulka revizí. Upravené oblasti výkresu byly navíc zvýrazněny pomocí mračen revizí.

Kontrola verzí je rozšířená v podnikání a právu. „Smluvní linka“ a „legální černá linka“ jsou skutečně některé z prvních forem kontroly revizí a stále se používají v obchodě a právu s různou mírou náročnosti. Pro elektronické sledování změn v souborech CAD se začínají používat ty nejpropracovanější techniky (viz správa produktových dat ), které nahrazují „ruční“ elektronickou implementaci tradiční kontroly revizí.

Modely správy zdrojů

Tradiční systémy řízení revizí používají centralizovaný model, kde všechny funkce řízení revizí probíhají na sdíleném serveru . Pokud se dva vývojáři pokusí změnit stejný soubor současně, bez nějakého způsobu správy přístupu mohou vývojáři navzájem přepsat práci. Centralizované systémy řízení revizí řeší tento problém v jednom ze dvou různých „modelů správy zdrojů“: zamykání souborů a sloučení verzí.

Atomové operace

Operace je atomická, pokud je systém ponechán v konzistentním stavu, i když je operace přerušena. Operace potvrzení je v tomto smyslu obvykle nejkritičtější. Závazky říkají systému kontroly revizí, aby skupina změn byla konečná a dostupná všem uživatelům. Ne všechny systémy kontroly revizí mají atomové závazky; pozoruhodně, CVS postrádá tuto funkci.

Uzamčení souboru

Nejjednodušší metoda prevence problémů se „ souběžným přístupem “ zahrnuje zamykání souborů, takže pouze jeden vývojář má současně přístup pro zápis do centrálních kopií těchto souborů „úložiště“. Jakmile jeden vývojář „odhlásí“ soubor, ostatní jej mohou přečíst, ale nikdo jiný jej nesmí změnit, dokud vývojář „nezaregistruje“ aktualizovanou verzi (nebo nezruší pokladnu).

Zamykání souborů má své výhody i nevýhody. Když uživatel provádí radikální změny v mnoha částech velkého souboru (nebo skupiny souborů), může poskytnout určitou ochranu před obtížnými konflikty sloučení. Pokud jsou však soubory ponechány výlučně uzamčeny příliš dlouho, mohou být ostatní vývojáři v pokušení obejít software pro kontrolu revizí a lokálně změnit soubory, což si vynutí obtížné manuální sloučení, když jsou ostatní změny konečně zapsány. Ve velké organizaci soubory mohou být ponechány „odhlášené“ a uzamčeny a zapomenuty, když se vývojáři pohybují mezi projekty - tyto nástroje mohou, ale nemusí usnadňovat zjištění, kdo má soubor rezervovaný.

Sloučení verze

Většina systémů pro správu verzí umožňuje více vývojářům upravovat stejný soubor současně. První vývojář, který „odbaví“ změny v centrálním úložišti, vždy uspěje. Systém může poskytovat zařízení ke sloučení dalších změn do centrálního úložiště a zachovat změny od prvního vývojáře, když se ostatní vývojáři přihlásí.

Sloučení dvou souborů může být velmi delikátní operace a obvykle je možné pouze v případě, že je struktura dat jednoduchá, jako v textových souborech . Výsledkem sloučení dvou obrazových souborů nemusí být vůbec obrazový soubor. Druhý vývojář, který kontroluje kód, se bude muset starat o sloučení, aby se ujistil, že změny jsou kompatibilní a že operace sloučení nezavádí vlastní logické chyby v souborech. Tyto problémy omezují dostupnost operací automatického nebo poloautomatického sloučení hlavně na jednoduché textové dokumenty, pokud není pro typy souborů k dispozici konkrétní slučovací modul .

Koncept vyhrazené úpravy může poskytnout volitelný způsob, jak explicitně zamknout soubor pro výhradní přístup pro zápis, i když existuje možnost sloučení.

Základní linie, štítky a značky

Většina nástrojů pro kontrolu revizí bude používat pouze jeden z těchto podobných výrazů (základní čára, štítek, značka) k označení akce identifikace snímku („označení projektu“) nebo záznamu snímku („zkuste to s výchozím X “) . V dokumentaci nebo diskusi se obvykle používá pouze jeden z termínů baseline , label nebo tag ; lze je považovat za synonyma.

Ve většině projektů jsou některé snímky významnější než jiné, například ty, které se používají k označení publikovaných vydání, větví nebo milníků.

Když jsou ve stejné souvislosti použity společně termín základní linie i označení nebo značka , označení a značka obvykle odkazují na mechanismus v rámci nástroje identifikace nebo pořizování záznamu snímku a základní linie označuje zvýšený význam jakéhokoli daného štítku nebo tag.

Většina formálních diskusí o správě konfigurace používá termín baseline .

Distribuovaná kontrola revizí

Distribuované systémy řízení revizí (DRCS) využívají přístup peer-to-peer, na rozdíl od přístupu centralizovaných systémů klient-server . Spíše než jediné centrální úložiště, na kterém se klienti synchronizují, je pracovní kopie základny kódů každého peera bona-fide úložiště. Distribuované řízení revizí provádí synchronizaci výměnou oprav (sad změn) z peer na peer. To má za následek některé důležité rozdíly od centralizovaného systému:

  • Ve výchozím nastavení neexistuje žádná kanonická referenční kopie kódové základny; pouze funkční kopie.
  • Běžné operace (jako jsou potvrzení, historie prohlížení a vrácení změn) jsou rychlé, protože není potřeba komunikovat s centrálním serverem.

Komunikace je spíše nutná pouze při tlačení nebo tažení změn od nebo od jiných vrstevníků.

  • Každá fungující kopie efektivně funguje jako vzdálená záloha kódové základny a její historie změn a poskytuje přirozenou ochranu před ztrátou dat.

Integrace

Některé pokročilejší nástroje pro řízení revizí nabízejí mnoho dalších zařízení, což umožňuje hlubší integraci s jinými nástroji a procesy softwarového inženýrství. Pluginy jsou často k dispozici pro IDE, jako jsou Oracle JDeveloper , IntelliJ IDEA , Eclipse a Visual Studio . Delphi , NetBeans IDE , Xcode a GNU Emacs (přes vc.el). Prototypy pokročilého výzkumu generují příslušné zprávy o potvrzení, ale fungují pouze na projektech s již velkou historií, protože zprávy o potvrzení jsou velmi závislé na konvencích a výstřednostech projektu.

Běžná terminologie

Terminologie se může lišit systém od systému, ale některé termíny v běžném používání zahrnují:

Základní linie
Schválená revize dokumentu nebo zdrojového souboru, ve které lze provádět následné změny. Podívejte se na základní linie, štítky a značky .
Obviňovat
Hledání autora a revize, která naposledy upravila konkrétní řádek.
Větev
Sada souborů pod správou verzí může být v určitém časovém okamžiku rozvětvená nebo rozvětvená, takže od té doby se mohou dvě kopie těchto souborů vyvíjet různou rychlostí nebo různými způsoby nezávisle na sobě.
Změna
Změnu (nebo rozdíl , nebo delta ) představuje konkrétní modifikaci na dokument pod kontrolou verzí. Granularita modifikace uvažované změny se mezi systémy správy verzí liší.
Seznam změn
Na mnoha systémech pro správu verzí s atomickými vícenásobnými potvrzeními seznam změn (nebo CL ), sada změn , aktualizace nebo oprava identifikuje sadu změn provedených v jednom potvrzení. To může také představovat sekvenční pohled na zdrojový kód, což umožňuje zkoumat zdroj z jakéhokoli konkrétního ID seznamu změn.
Překontrolovat
Aby check out (nebo co ), je vytvořit místní pracovní kopii z úložiště. Uživatel může určit konkrétní revizi nebo získat nejnovější. Termín 'pokladna' může být také použit jako podstatné jméno k popisu pracovní kopie. Když byl soubor rezervován ze sdíleného souborového serveru, nelze jej upravit jinými uživateli. Představte si to jako hotel, když se odhlásíte, přestanete mít přístup k jeho vybavení.
Klon
Klonování znamená vytvoření úložiště obsahujícího revize z jiného úložiště. To je ekvivalentní tlačení nebo tažení do prázdného (nově inicializovaného) úložiště. Jako podstatné jméno lze říci, že dva repozitáře jsou klony, pokud jsou synchronizovány a obsahují stejné revize.
Commit (podstatné jméno)
„Potvrzení“ nebo „revize“ (SVN) je modifikace, která se použije v úložišti.
Commit (sloveso)
Chcete-li spáchat ( check in , ci nebo, více zřídka, instalace , předložit nebo záznam ) je napsat nebo sloučit změny provedené v pracovní kopii zpět do úložiště. Potvrzení obsahuje metadata, obvykle informace o autorovi a zprávu o potvrzení, která popisuje změnu.
Konflikt
Ke konfliktu dochází, když různé strany provedou změny ve stejném dokumentu a systém není schopen změny sladit. Uživatel musí konflikt vyřešit kombinací změn nebo výběrem jedné změny ve prospěch druhé.
Delta komprese
Většina softwaru pro řízení revizí používá delta kompresi , která zachovává pouze rozdíly mezi po sobě jdoucími verzemi souborů. To umožňuje efektivnější ukládání mnoha různých verzí souborů.
Dynamický stream
Stream, ve kterém jsou některé nebo všechny verze souborů zrcadly verzí nadřazeného streamu.
Vývozní
export je akt získání souborů z úložiště. Je to podobné jako při pokladně, kromě toho, že vytváří čistý adresářový strom bez metadat pro řízení verzí použitých v pracovní kopii. To se často používá například před zveřejněním obsahu.
Vynést
Viz tah .
Vpřed integrace
Proces sloučení změn provedených v hlavním kufru do vývojové (funkce nebo týmové) větve.
Hlava
Také se někdy nazývá spropitné , což se týká posledního potvrzení, buď do kufru, nebo do větve. Kmen a každá větev mají svou vlastní hlavu, ačkoli HEAD se někdy volně používá k označení kmene.
Import
import je akt kopírování lokálního stromu adresářů (který v současné době není funkční kopií) do úložiště poprvé.
Inicializovat
vytvořit nové, prázdné úložiště.
Prokládané delty
některý software pro řízení revizí používá prokládané delty , což je metoda, která umožňuje ukládání historie textových souborů efektivněji než pomocí komprese Delta .
Označení
Viz štítek .
Zamykání
Když vývojář uzamkne soubor, nikdo jiný jej nemůže aktualizovat, dokud jej neodemknete. Zamykání může být podporováno systémem pro správu verzí nebo prostřednictvím neformální komunikace mezi vývojáři (aka sociální zamykání ).
Hlavní trať
Podobně jako kufr , ale pro každou větev může existovat hlavní řada.
Spojit
Sloučení nebo integrace je operace, ve kterých jsou dvě sady změn jsou aplikovány do souboru nebo sady souborů. Některé ukázkové scénáře jsou následující:
  • Uživatel, který pracuje na sadě souborů, aktualizuje nebo synchronizuje svou pracovní kopii provedenými změnami a zapsanými ostatními uživateli do úložiště.
  • Uživatel se pokusí zapsat soubory, které byly aktualizovány jinými od doby, kdy byly soubory rezervovány , a software pro kontrolu revizí soubory automaticky sloučí (obvykle po vyzvání uživatele, zda by mělo pokračovat s automatickým sloučením, a v některých případech pouze činí tak, pokud lze sloučení jasně a rozumně vyřešit).
  • Je vytvořena větev , kód v souborech je nezávisle upravován a aktualizovaná větev je později začleněna do jediného sjednoceného kufru .
  • Sada souborů je rozvětvená , což je problém, který existoval před tím, než je větvení opraveno v jedné větvi, a oprava je poté sloučena do druhé větve. (Tento typ selektivního sloučení je někdy známý jako výběr třešní, aby se odlišil od úplného sloučení v předchozím případě.)
Podporovat
Akt kopírování obsahu souboru z méně kontrolovaného umístění do více kontrolovaného umístění. Například z pracovního prostoru uživatele do úložiště nebo ze streamu do jeho nadřízeného.
Táhnout, tlačit
Zkopírujte revize z jednoho úložiště do druhého. Pull je iniciováno přijímajícím úložištěm, zatímco push je iniciováno zdrojem. Fetch je někdy používán jako synonymum pro pull , nebo ve smyslu tahu následovaného aktualizací .
Vytáhnout žádost
Vývojář žádající ostatní, aby sloučili jejich „postrčené“ změny.
Úložiště
Úložiště (nebo „repo“) je místo, kde jsou aktuální i historické údaje Files uloženy, často na serveru. Někdy se také nazývá depo .
Odhodlání
Akt zásahu uživatele k řešení konfliktu mezi různými změnami stejného dokumentu.
Reverzní integrace
Proces sloučení různých týmových větví do hlavního kufru verzovacího systému.
Revize
Také verze : Verze je jakákoli změna formy. V SVK je revize stav v časovém bodě celého stromu v úložišti.
Podíl
Akt zpřístupnění jednoho souboru nebo složky ve více větvích současně. Když se sdílený soubor změní v jedné větvi, změní se v ostatních větvích.
Proud
Kontejner pro rozvětvené soubory, který má známý vztah k jiným takovým kontejnerům. Toky tvoří hierarchii; každý stream může zdědit různé vlastnosti (jako verze, obor názvů, pravidla pracovního postupu, předplatitelé atd.) ze svého nadřazeného streamu.
Štítek
Štítek nebo etiketa se týká významného snímek v čase, konzistentní napříč mnoha soubory. Tyto soubory v tom okamžiku mohou být všechny označeny uživatelsky přívětivým, smysluplným názvem nebo číslem revize. Podívejte se na základní linie, štítky a značky .
Kmen
Unikátní vývojová linie, která není pobočkou (někdy se také nazývá Baseline, Mainline nebo Master)
Aktualizace
Aktualizace (nebo synchronizace , ale synchronizace může také znamenat kombinovaný tlak a pull ) sloučí změny provedené v úložišti (ze strany jiných lidí, například) do místní pracovní kopie . Aktualizace je také termín používaný některými nástroji CM (CM+, PLS, SMS) pro koncept balíčku změn (viz seznam změn ). Synonymum pro pokladnu v systémech kontroly revizí, které vyžadují, aby každé úložiště mělo přesně jednu pracovní kopii (běžnou v distribuovaných systémech)
Odemykání
uvolnění zámku.
Pracovní kopie
Pracovní kopie je místní kopie souborů z úložiště v době, specifické nebo revizí. Veškerá práce se soubory v úložišti se zpočátku provádí na pracovní kopii, odtud název. Koncepčně jde o sandbox .

Viz také

Poznámky

Reference

externí odkazy

  • „Vizuální průvodce správou verzí“, lépe vysvětleno.
  • Dřez, Eric, „Source Control“, SCM (postup). Základy správy verzí.