| podvracení | |
|---|---|
| Typ | centralizovaný systém správy verzí [d] , projekt Apache Foundation [d] aotevřeným zdrojovým kódem |
| Autor | CollabNet [d] |
| Vývojář | Apache Software Foundation |
| Zapsáno v | C [4] [5] , Python [4] , C++ [6] [7] a Java [6] [7] |
| Operační systém | GNU/Linux [8] , Microsoft Windows [8] , macOS [8] a BSD [8] |
| První vydání | 20. října 2000 [1] |
| Nejnovější verze | |
| Čitelné formáty souborů | Formát výpisu SVN (v1) [d] , formát výpisu SVN (v2) [d] , formát výpisu SVN (v3) [d] a formát výpisu SVN (obecný) [d] |
| Vygenerované formáty souborů | Formát výpisu SVN (v1) [d] , formát výpisu SVN (v2) [d] , formát výpisu SVN (v3) [d] a formát výpisu SVN (obecný) [d] |
| Licence | Licence Apache 2.0 [9] |
| webová stránka | subversion.apache.org _ |
| Mediální soubory na Wikimedia Commons | |
Subversion [10] (také známý jako " SVN " [11] ) je bezplatný systém centralizované správy verzí oficiálně vydaný v roce 2004 společností CollabNet . Od roku 2010 je Subversion projektem Apache Software Foundation a oficiálně se nazývá Apache Subversion (registrovaná ochranná známka [12] ).
Cílem projektu na počátku vývoje bylo nahradit [13] [14] tehdy rozšířený Concurrent Versions System (CVS), který je dnes považován za zastaralý [15] [16] [17] . Subversion implementuje všechny hlavní vlastnosti CVS a neobsahuje některé z jeho nedostatků.
Subversion stále používají některé komunity s otevřeným zdrojovým kódem (včetně těch, které dříve používaly CVS ), ale téměř všechny velké projekty přešly na DVCS . Mezi posledními uživateli Subversion mezi otevřenými projekty zůstává FreeBSD , ale také oznámili přechod na Git [18] , a například i Free Pascal . Subversion je již dlouhou dobu používán takovými známými projekty jako Apache , GCC , FFmpeg , LLVM . Subversion se také používá v soukromých projektech a korporátním světě, ale je těžké odhadnout, jak široce. Hosting Subversion , včetně projektů s otevřeným zdrojovým kódem, poskytují také oblíbené hostingové projekty SourceForge.net , Tigris.org , Google Code a BountySource .
V roce 2007 analytická firma Forrester ohodnotila Subversion jako „jediného lídra v kategorii Standalone Software Configuration Management (SCM) a silného přispěvatele v kategorii Software Configuration and Change Management (SCCM)“ při porovnávání výhod a nevýhod různých systémy . [19]
Podle statistik o používání linuxových balíčků – distribucí Debian [20] a Ubuntu [21] dosáhl počet aktivních uživatelů Subversion vrcholu kolem roku 2010 a od roku 2016 začal klesat. Stále však existuje více projektů využívajících Subversion než CVS , Mercurial a Bazaar (stav k srpnu 2019 ).
Oficiální dokumentace je umístěna [22] v knize vydané nakladatelstvím O'Reilly Media , která je volně dostupná [23] a přidávají ji autoři, když jsou vydány nové verze SVN. Vydává také své překlady do řady jazyků včetně ruštiny, ale přestože anglické verze knihy nyní popisují verze 1.8 a 1.7, existují pouze knihy v ruštině, které popisují verze do 1.4 včetně [24] .
Vývoj Subversion začal v roce 2000 z iniciativy a s finanční podporou CollabNet. Iniciátoři projektu chtěli vytvořit bezplatný systém správy verzí, v zásadě podobný CVS, ale bez jeho chyb a nepříjemností . V té době neexistovaly nejlepší programy této třídy se svobodnou licencí, CVS bylo de facto standardem mezi vývojáři svobodného softwaru. Tím, že si jej zvolili jako základ, vývojáři Subversion doufali, že zjednoduší vývoj využitím již osvědčených konceptů a zároveň usnadní mnoha uživatelům CVS migraci na nový systém. [25]
Hlavní události v historii vývoje Subversion.
Subversion je centralizovaný systém (na rozdíl od distribuovaných systémů jako Git nebo Mercurial ), což znamená, že data jsou uložena v jediném úložišti. Úložiště může být umístěno na místním disku nebo na síťovém serveru .
Práce v Subversion se příliš neliší od práce v jiných centralizovaných systémech správy verzí. Klienti zkopírují soubory z úložiště, aby vytvořili místní pracovní kopie, poté provedou změny v pracovních kopiích a tyto změny odešlou do úložiště. K úložišti může přistupovat více klientů současně. Subversion primárně používá model kopírování-upravování-sloučení pro spolupráci na souborech . Také pro neslučitelné soubory (různé binární formáty souborů) můžete použít model lock-modify-unlock .
Při ukládání nových verzí se používá delta komprese : systém najde rozdíly mezi novou verzí a předchozí a zapíše je pouze, aby nedocházelo k duplicitě dat.
Při použití přístupu WebDAV je podporováno i transparentní verzování – pokud se jakýkoli klient WebDAV otevře pro zápis a poté uloží soubor uložený na síťové sdílené položce, automaticky se vytvoří nová verze.
Subversion nabízí dvě možnosti organizace repozitářů [40] . Repozitáře prvního typu slouží k ukládání databáze založené na Berkeley DB , repozitáře druhého typu jsou běžné soubory speciálního formátu (přístup k datům je organizován pomocí vlastních knihoven, bez použití databází třetích stran). Vývojáři Subversion často označují úložiště jako "souborový systém", a proto se druhý typ nazývá FSFS, což znamená (verzovaný) souborový systém ( anglicky File System ) nad (běžným) souborovým systémem.
Oba typy úložišť poskytují při správné organizaci dostatečnou spolehlivost [41] (Berkeley DB používá zámky souborů, nelze jej tedy použít na některých síťových souborových systémech, které zámky nepodporují), každý z nich má své výhody a nevýhody. Předpokládá se, že FSFS se snáze správně konfiguruje, vyžaduje méně pozornosti správce. Navíc před vydáním 1.4 mohla úložiště využívající Berkeley DB za určitých podmínek skončit v takzvaném zaklíněném stavu ; k obnovení jeho funkčnosti byl nutný zásah administrátora.
Počínaje verzí 1.2 se pro nová úložiště standardně používá FSFS. S vydáním 1.8 bylo používání Berkeley DB zastaralé [37] . Nové funkce, které budou přidány v budoucích verzích, nemusí fungovat na serverech používajících Berkeley DB. Podpora pro Berkeley DB může být v budoucnu ukončena.
Subversion poskytuje následující způsoby přístupu k úložišti:
Všechny tyto metody lze použít pro práci s oběma typy repozitářů (FSFS a Berkeley DB). Pro přístup ke stejnému úložišti lze současně použít různé metody.
Z pohledu uživatele je úložiště Subversion "dvourozměrný" souborový systém . Objekty v úložišti ( soubory a adresáře ) jsou identifikovány dvěma " souřadnicemi ": názvem a číslem revize . Jinými slovy, úložiště je pole snímků (revizí) stromu souborů a adresářů, indexovaných podle čísla revize. Každý takový snímek je běžný (jednorozměrný) souborový systém.
Je-li třeba uvést konkrétní revizi objektu, použije se zápis ve tvaru: имя@ревизия, například /main.c@29 soubor /main.c v revizi 29. Takové označení revize použité k objasnění názvu se nazývá peg revize .
Na Obr. 1 znázorňuje grafické znázornění souborového systému: svislá osa odpovídá množině jmen, vodorovná osa množině revizí.
Názvy souborůNázev objektu souborového systému v Subversion je tvořen podle stejných pravidel jako v operačních systémech podobných UNIX: existuje pouze jeden kořenový adresář, prvky cesty jsou odděleny lomítkem ("/"). Objekty souborového systému jsou soubory a adresáře (stejně jako symbolické odkazy , které jsou emulovány z běžných souborů nastavením atributu svn:special).
Čísla revizíČíslo revize v Subversion je přirozené číslo (nebo 0 pro úplně první revizi), které řeší číslo stavu úložiště, když se mění data, která obsahuje. Každé úspěšné potvrzení generuje přesně jednu novou revizi do úložiště, takže N -tá revize je stav úložiště po N- tém potvrzení.
V Subversion revize charakterizuje stav nikoli jednoho souboru, ale celého úložiště jako celku. Například revize 32 (na obrázku tečkovaná) je stav čtyř souborů a dvou adresářů, které v té době existovaly v úložišti.
Číslo revize je analogické času v tom smyslu, že nižší čísla revizí odpovídají dřívějším stavům úložiště a vyšší čísla revizí odpovídají pozdějším.
Číslo revize lze považovat za jakési časové razítko v historii úložiště. Navíc každé číslo revize má absolutní hodnotu spojenou s časem, kdy byla revize provedena ( vlastnost svn:date ). Zadání čísla revize je však pohodlnější než zadání času, protože nedochází k záměně s časovými pásmy, zadání čísla je kratší a číslo revize nelze změnit.
Provozní a základní revizeČíslo revize se používá ve dvou různých kontextech :
Revize se nazývá provozní , pokud specifikuje revizi nebo rozsah revizí, na které má být operace aplikována , například:
svn log -r 199:230 http://some.pathV tomto příkladu je příkaz proveden svn logpro rozsah revizí 199:230, což je rozsah online revizí.
Zadání pouze názvu souboru a online revize však může někdy nejednoznačně ukazovat na objekty úložiště. Například v situaci znázorněné na Obr. 2, při spuštění následujícího příkazu existuje nejednoznačnost:
svn log -r 29:33 http://some.path/bar.txtPříkaz určuje rozsah online revizí ( 29:33), ale oblasti zvýrazněné modře a zeleně na obrázku lze stejně tak považovat za historii souboru /bar.txtv rozsahu revizí 29:33. V takových případech je také nutné specifikovat pivotní revizi, aby se vyřešila nejednoznačnost. Revize jádra je číslo revize zadané navíc k URL objektu systému souborů (pomocí URL@ревизияzápisu " "). Název pochází z anglického slova peg , které lze přeložit jako „tyč“ nebo „kolíček“. Revize pivotu označuje řetězec stavů, do kterého zadaný pár patří URL@ревизия, a tak jednoznačně identifikuje objekt úložiště, na který má být příkaz aplikován. V níže uvedeném příkladu první příkaz vytiskne článek zvýrazněný na obrázku modře a druhý příkaz vytiskne článek zvýrazněný zeleně:
svn log -r 29:33 http://some.path/file.txt@32 svn log -r 29:33 http://some.path/bar.txt@34Jako základní revize by měl být specifikován nejnovější stav objektu zájmu. Důvodem je to, že státní řetězec je jednoznačně sledován „zpět“, ale nikoli „vpřed“. Například adresa URL s revizí pivotu http://some.path/foo.txt@31 patří do dvou stavových řetězců (zvýrazněných zeleně a šedě). Z těchto dvou řetězců se zadaná adresa URL zaměřuje na šedý řetězec, to znamená, že při pohybu „vpřed“ od základní revize jsou operace kopírování ignorovány.
Operace se souborovým systémemNásledující operace lze provádět s objekty souborového systému v úložišti Subversion [42] (viz obrázek 1). Závorky označují krátké pojmenování operace v zápisu příkazu svn status.
Pracovní kopie je lokální kopie části dat z úložiště vytvořená klientským programem Subversion, která obsahuje kromě samotných dat i některé servisní informace (skryté adresáře s názvem .svn). Servisní informace jsou nezbytné pro správné fungování pracovní kopie; v servisních údajích nelze nic změnit. Nejmenší jednotka dat, kterou lze načíst z úložiště jako pracovní kopii, je adresář. Obsah adresáře nemusí být plně extrahován: mohou být například vyloučeny jednotlivé soubory nebo podadresáře. Není však možné rezervovat jeden soubor z úložiště jako pracovní kopii.
Jakýkoli podadresář pracovní kopie Subversion 1.6 a dřívějších je také plnou pracovní kopií, protože každý adresář obsahuje svá provozní data (adresáře .svn). Od verze 1.7 má každá pracovní kopie pouze jeden adresář .svnv kořenovém adresáři svého adresáře.
Pracovní kopie je samostatná v tom smyslu, že Subversion neukládá žádná data související s pracovní kopií mimo ni. Proto s jednou pracovní kopií můžete vytvořit několik dalších kopií jednoduchým kopírováním, aniž byste utráceli síťový provoz.
V adresářích služeb pracovní kopie je mimo jiné uložena tzv. čistá kopie ( angl. pristine copy ) - soubory pracovní kopie v nezměněné podobě, tak jak byly extrahovány z úložiště (pro svn je to revize s názvem BASE). Čisté kopie vám umožní rychle zobrazit a vrátit zpět místní změny bez přístupu k úložišti. Velikost pracovní kopie na disku je však zhruba dvakrát větší (data + čistá kopie dat) než velikost samotných dat. Tento přístup je způsoben tím, že diskové prostředky jsou levnější a dostupnější než prostředky datové sítě .
Vytvoření pracovní kopie je obvykle prvním a nezbytným krokem k potvrzení místních změn, protože do úložiště lze odevzdat pouze změny provedené v pracovní kopii. Výjimkou jsou operace, které lze provádět přímo na úložišti bez vytvoření pracovní kopie.
TransakceÚložiště v Subversion je organizováno ve formě transakcí s vlastnostmi atomicity a izolace ze sady vlastností ACID . Systém správy verzí tak zaručuje integritu, konzistenci a dostupnost úložiště kdykoli.
Tyto vlastnosti nejsou zaručeny pro pracovní kopii Subversion - na rozdíl od úložiště může být v přechodném nebo uzamčeném stavu, pokud dojde k jeho zhroucení nebo přerušení (to znamená, že svn cleanuppřed pokračováním bude nutné jej obnovit příkazem nebo znovu vytvořit).
Místní a vzdálené příkazové formulářeVšechny příkazy klienta Subversion lze rozdělit do následujících skupin:
Formálně Subversion neklade žádná omezení na souborovou strukturu projektu – může to být cokoliv v rámci pravidel pro pojmenovávání objektů v souborovém systému. Existují však pokyny, které usnadňují práci s větvemi a značkami. V nejjednodušším případě se doporučuje vytvořit alespoň tři podadresáře v kořenovém adresáři úložiště:
/. trunk branches tagsCelá souborová struktura projektu (hlavní vývojová linie) musí být obsažena v podadresáři ,trunk podadresář branchesmusí obsahovat větve projektu a tags značky . Například následující adresářová struktura úložiště:
/. trunk branches branch_1 tags tag_1 tag_2
předpokládá, že projekt ( trunk) má jednu větev „ branch_1“ a dva štítky „ tag_1“ a „ tag_2“. Každý z těchto adresářů ( , a trunk) branch_1obsahuje kopii odpovídající verze projektu. tag_1tag_2
Pokud je v úložišti několik (pod)projektů, vytvoří se pro každý (pod)projekt následující struktura podadresářů:
/. project1 trunk branches tags project2 trunk branches tagsTo znamená, že kořenový adresář obsahuje adresáře projektu a každý z nich má svůj vlastní trunk, branches, tags, který se vztahuje pouze k tomuto projektu. Popsané adresářové struktury úložiště jsou pouze příklady, v praxi lze úložiště organizovat způsobem, který nejlépe vyhovuje danému konkrétnímu případu. [43] [44]
Dalším způsobem, jak uložit více projektů, je vytvořit více úložišť. Projekty, které spolu nijak nesouvisí, by měly být umístěny v různých úložištích, protože mezi úložišti nelze provádět operace kopírování, přesouvání a slučování. Několik úložišť lze v případě potřeby sloučit do jednoho se zachovanou historií revizí (importem pomocí příkazu svnadmin loads parametrem --parent-dir).
VětveSubversion používá k implementaci větví a značek "souborový" model (stejný jako Perforce [45] ), tj. větev je pouze adresář (můžete také vytvořit větev z jednoho souboru místo adresáře). Nová větev se vytvoří příkazem svn copy. Větev lze vytvořit v libovolném adresáři úložiště, ale má smysl dodržovat výše popsané konvence o tom, kde vytvářet nové větve. Další informace o pobočkách naleznete v části Větvení a slučování .
TagyVytvoření štítku se také provádí příkazem svn copy, to znamená, že je to technicky stejné jako vytvoření větve. Rozdíl je pouze ve způsobu použití: předpokládá se, že údaje v popisku nikdo nezmění (potvrdí v něm změny). Například na Obr. 1 značka vytvořená v revizi 29: adresář /trunkz revize 27 zkopírován pod názvem /tags/R1. Nyní, pokud nezměníte data v adresáři /tags/R1, zůstane navždy přesnou kopií adresáře /trunk@27, to znamená, že to bude štítek .
Koncept tagů používaný v Subversion se liší od konceptu tagů v jiných systémech správy verzí. Typicky je štítek symbolický název, který adresuje sadu souborů a jejich stav. V Subversion štítek kopíruje sadu souborů a jejich stav. Kopírování štítků v Subversion má své výhody a nevýhody.
výhody:
nedostatky:
Jednou z důležitých vlastností Subversion je podpora vlastností, tedy textových párů jméno = hodnota , které lze nastavit na objektech v obchodě. Vlastnosti se používají ve dvou různých kontextech: pro objekty souborového systému a pro revize.
Vlastnosti objektů systému souborůKaždému souboru nebo adresáři v úložišti lze přiřadit sadu vlastností. Změny vlastností se ukládají do historie stejným způsobem jako změny systému souborů. Uživatelé mohou nastavit vlastnosti s libovolným názvem; existuje také předdefinovaná sada vlastností nástroje, které používá klientský program Subversion (názvy vlastností nástroje mají předponu "svn: ").
Vlastnosti souboru svn:executable Udělá soubor spustitelným (pro pracovní kopie pod operačními systémy rodiny UNIX ). svn:mime-type Ukládá typ MIME souboru. Ovlivňuje způsob, jakým fungují příkazy, které ukazují rozdíly v souborech a slučují změny (slučování). svn:keywords Seznam klíčových slov ( angl. keywords ), která budou v souboru nahrazena odpovídajícími hodnotami. Aby došlo k nahrazení, klíčové slovo musí být v souboru přítomno jako $keyword$. Používá se k automatické aktualizaci hodnot v souboru, které se mění z verze na verzi (například číslo revize). svn:eol-style Určuje pravidlo pro převod znaků konce řádku ( EOL ) v textovém souboru . Používá se v případech, kdy soubor musí mít specifický typ znaku EOL. Obvykle se používá "nativní" - v tomto případě typ znaků na konci řádku odpovídá typu přijatému v operačním systému, ve kterém se vytváří pracovní kopie. svn:needs-lock Označuje, že soubor bude při načtení z úložiště pouze pro čtení. Tato vlastnost je určena k použití ve spojení s blokovacím mechanismem . Odmítnutí zápisu do souboru je připomínkou, abyste získali zámek souboru před jeho úpravou: když je zámek získán, klientský program Subversion automaticky učiní soubor zapisovatelný (opětovné uvolnění zámku způsobí, že soubor nebude upravitelný). Zámky lze použít bez nastavení této vlastnosti. To se však nedoporučuje, protože existuje riziko, že jiný uživatel může začít upravovat zamčený soubor, a to bude odhaleno až po potvrzení změn. svn:special Tato vlastnost není určena k tomu, aby ji nastavovali nebo upravovali uživatelé. V současné době se používá k ukládání symbolických odkazů v úložišti. Když je do úložiště přidán symbolický odkaz, vytvoří se v úložišti soubor s příponou svn:special. Když je tento soubor vypůjčen v systému podobnému UNIXu , klientský program Subversion jej převede zpět na odkaz. svn:mergeinfo Ukládá informace o tom, které cesty byly sloučeny do tohoto souboru. Vlastnost byla představena ve verzi 1.5, používá se pro sledování sloučení . Je to sada řetězců ve tvaru název_souboru: rozsah_revizí . Zde název_souboru je úplný (s cestou z kořenového adresáře souborového systému úložiště) název souboru nebo adresáře, ze kterého byl sloučen zadaný rozsah revizí. Řádky jsou automaticky aktualizovány během operací sloučení; při následných sloučeních bere Subversion v úvahu dříve přidané řádky, čímž se vyhne opakovanému slučování stejných změn. Nedoporučuje se měnit vlastnost ručně – může to narušit mechanismus sledování sloučení.svn:mergeinfo Vlastnosti adresáře svn:ignore Seznam vzorů jmen souborů a adresářů, které bude klientský program Subversion v tomto adresáři ignorovat. Tato vlastnost je podobná souboru .cvsignorev CVS . Vlastnost je zpravidla nakonfigurována tak, že klientský program "nevidí" soubory a adresáře, které jsou automaticky vytvářeny různými programy a neměly by mít verzi (například objektové soubory , dočasné soubory atd.). Tato vlastnost se nevztahuje na podadresáře. svn:externals Umožňuje automaticky extrahovat sadu adresářů do pracovní kopie zadáním jejich URL (můžete i z jiného úložiště). svn:mergeinfo Stejné jako u souborů . Vlastnosti revizeDruhým typem objektu, pro který existují vlastnosti, jsou samotné revize. V tomto případě mohou být názvy vlastností také jakékoli; některé vlastnosti s předponou "svn: " mají zvláštní význam. Rozdíl mezi vlastnostmi revizí a vlastnostmi objektů systému souborů spočívá v tom, že pro prvně jmenované není koncept historie verzí použitelný (protože konkrétní hodnota vlastnosti je přiřazena jedné revizi). Jinými slovy, vlastnosti revize lze změnit, ale stará hodnota se ztratí. Ve výchozím nastavení jsou změny vlastností revize zakázány; aby administrátor mohl vytvořit skript ( angl. hook ) obsluhující událost pre-revprop-change.
svn:date Datum a čas vytvoření revize. svn:author Jméno uživatele, který provedl změny zahrnuté v této revizi. svn:log Popis změn provedených v této revizi (text zadaný uživatelem při potvrzení změn).Vlastnosti revize zpravidla mění pouze správce úložiště za účelem opravy nesprávných údajů. Pokud například uživatel zapomněl při provádění změn zadat textový popis, může správce tento popis vytvořit úpravou souboru svn:log.
Typická iterace pracovního postupu se Subversion zahrnuje následující kroky.
Větvení je důležitým aspektem fungování systémů správy verzí, protože typické techniky verzování [47] (alespoň ve vývoji softwaru ) zahrnují použití větví. Subversion má poměrně pokročilé možnosti větvení a slučování ( nepodporuje však slučování přejmenovaných souborů a adresářů).
Na Obr. Obrázek 3 obvykle ukazuje příklad vývoje větví v úložišti. Zelená barva znázorňuje hlavní linii vývoje projektu ( angl. mainline, kmen ), žlutá - větve, modrá - tagy, purpurová - větev, jejíž vývoj byl ukončen. Červené šipky ukazují sloučení změn.
Vytváření větvíNová větev (stejně jako tag ) se vytvoří příkazem svn copy, který vytvoří kopii v úložišti s děděním historie revizí zdroje ( operace A+ ). K vytváření větví byste měli vždy používat "vzdálenou" formu příkazu svn copy, například:
svn kopie http://.../trunk/dir http://.../branches/branch_name -m "Vytvoření větve dir"Výsledná kopie bude větev (nebo značka, podle toho, jak s ní pracujete). V budoucnu lze změny provedené na větvi provést ve zdroji, ze kterého byla tato větev vytvořena, takové šíření změn se nazývá merge .
Kopírovací operace v Subversion jsou levné ( angl. Cheap copy ), to znamená, že vyžadují malé pevné množství času a místa na disku. Úložiště je navrženo tak [48] , že při žádném kopírování nedochází k duplikování dat, ale k vytvoření odkazu na zdroj (obdoba pevného odkazu ), nicméně tento mechanismus je čistě interní - z pohledu uživatele zobrazení, dochází k vytvoření kopie. Díky vysoké efektivitě větvení lze větve vytvářet tak často, jak je potřeba (avšak slučování - nezbytný doplněk větvení - je v Subversion pomalejší než v jiných moderních systémech správy verzí).
Práce s větvemiObecně se práce na větvi neliší od práce na hlavní vývojové linii ( kmen ). Specifické příkazy jsou vyžadovány pouze pro činnosti zahrnující více než jednu větev. Tyto příkazy zahrnují (kromě příkazu create branch svn copy):
Celý cyklus práce s větvemi zpravidla zahrnuje následující kroky:
Sloučení v Subversion je aplikace na větev sady změn provedených na jiné (nebo stejné) větvi. Chcete-li implementovat sloučení, musíte použít příkaz svn merge - ten aplikuje sadu změn na pracovní kopii; pak musíte provést změny ( svn commit).
Slučování terminologie je poněkud matoucí. Termín sloučení není zcela přesný, protože nedochází ke slučování poboček jako takové . Kromě toho byste neměli ztotožňovat merge a příkaz : za prvé, pro sloučení musíte provést (kromě ) řešení konfliktů a odevzdat, a za druhé, aplikace není omezena na sloučení. svn mergesvn mergesvn merge
Další použití příkazu svn mergePříkaz svn mergelze použít pro více než jen sloučení. Příkaz ve skutečnosti provádí změny v pracovní kopii rovnající se rozdílu mezi dvěma adresáři nebo soubory v úložišti , proto svn mergeje univerzálním nástrojem pro přenos změn. Zde je několik příkladů použití příkazu svn merge:
Příkaz se používá k vytvoření trezoru svnadmin create. Tato operace vytvoří prázdné úložiště v zadaném adresáři.
Níže je srovnání parametrů systémů Subversion a CVS, protože Subversion je umístěn přesně jako vylepšení CVS. Srovnání se provádí pouze u těch parametrů, ve kterých se tyto systémy liší. Celkově Subversion překonává CVS ve všech směrech kromě štítků v konvenčním smyslu (to znamená štítků, které řeší objekty souborového systému).
| Parametr | podvracení | CVS |
|---|---|---|
| Schopnosti | ||
| Katalogy | Sleduje verze nejen souborů, ale i adresářů. | Verze adresářů nejsou sledovány, to znamená, že adresářová struktura je stejná (ta, která v úložišti momentálně existuje) pro všechny revize a všechny větve. Pokud změníte adresářovou strukturu, pak při extrahování starých stavů získáme správné (staré) revize souborů, ale ve špatné (existující v době extrakce) adresářové struktuře. |
| Transakce | Atomicita vícesouborových commitů. | Atomicita je pouze na úrovni odevzdání jednoho souboru. Odevzdání změn do více souborů je ve skutečnosti rozděleno do posloupnosti odevzdání jednotlivých souborů. Pokud je taková sekvence potvrzení přerušena, pak některé soubory zůstanou potvrzené, zatímco jiné zůstanou nepotvrzené. |
| Changesets | Jsou podporovány sady změn . | Sady změn nejsou podporovány. |
| Úpravy názvu souboru | Podporuje kopírování, přesouvání a přejmenování souborů a adresářů bez ztráty historie změn. | Při kopírování, přesouvání a přejmenovávání souborů nemá soubor s novým názvem žádnou historii, to znamená, že spojení se starým názvem a jeho historií verzí je zcela ztraceno. Totéž pro soubory uvnitř adresáře při úpravě jeho názvu [49] . |
| vlastnosti | Každý soubor a adresář může mít přidruženou libovolnou sadu vlastností, sestávající z názvu a hodnoty. Vlastnosti jsou také pod kontrolou verzí. | Vlastnosti nejsou podporovány. |
| Zámky | Je podporováno volitelné zamykání souborů (od verze 1.2). | Zámky nejsou podporovány, ale existuje podobný mechanismus zvaný sledování . |
| větví | Větve ( branch , viz Glosář ) jsou implementovány v prostoru cesty. To znamená, že pro vytvoření větve se adresář zkopíruje (kopií bude větev). Vytváření takových kopií je rychlá operace, která není náročná na zdroje, protože data nejsou duplikována , místo toho je opravena nová verze, která se od předchozí liší pouze umístěním souborů. | Větve jsou realizovány ve „třetí dimenzi“. To znamená, že soubor na větvi je adresován třemi parametry: cesta v systému souborů, revize (nebo nějaký jiný způsob, jak označit revizi, jako je čas), název větve . |
| Tagy | Neexistují žádné značky ( tag , viz slovník ) jako takové. Místo toho se používá hierarchie adresářů - pro štítek (stejně jako pro větev) je vytvořen samostatný adresář. Tag je větev, na které se podle konvence neprovádějí žádné další změny. Štítek je kopie označeného stavu souborů a adresářů. | Značky jsou podporovány. Štítek se týká označeného stavu souborů. |
| Účinnost | ||
| Výměna klient-server | Jakékoli aktualizace verzí mezi klientem a serverem pouze přenášejí rozdíly mezi soubory, což může výrazně snížit provoz v síti. | Rozdíly jsou přenášeny ze serveru na klienta a celý objekt je přenášen z klienta na server. |
| Binární soubory | Pracuje stejně efektivně s textovými i binárními soubory . | Práce s binárními soubory je méně efektivní: každá nová verze je uložena v úložišti celá. |
| Vytváření větví a štítků | Vyžaduje malé pevné množství času a místa na disku. | Časové náklady jsou vysoké (v závislosti na počtu zapojených souborů). Názvy větví a značek jsou uloženy redundantně (ve všech zúčastněných souborech). |
| Režie v pracovní kopii | Adresáře služeb pracovní kopie ukládají čistou kopii. Procházení a vracení místních změn je tedy rychlé (bez přechodu do úložiště), ale velikost pracovní kopie na disku je přibližně dvakrát větší než velikost samotných dat. | Čistá kopie se neukládá, velikost pracovní kopie je přibližně stejná jako velikost dat. V důsledku toho operace zobrazení a vrácení pro místní změny vyžadují přístup k úložišti a jsou pomalé. |
| Spotřeba paměti na serveru | Méně [50] . | Více. |
Existuje program cvs2svn navržený tak, aby převedl CVS repozitář na hotový Subversion repozitář (nebo git repozitář ) nebo na textový výpis, který pak lze importovat do repozitáře pomocí svnadmin. Zároveň cvs2svn ukládá všechny informace obsažené v úložišti CVS: větve, značky, popisy změn, jména autorů, data odevzdání. Kromě toho jsou změny v různých souborech potvrzené společně převedeny do jedné revize.
Rozdíly v použití Rozdíly ve zpracování souborůV CVS se přesouvání (přejmenování) a kopírování souborů a adresářů provádí opětovným přidáním objektu s novým názvem a (při přesouvání a přejmenování) smazáním starého objektu. Při této práci se soubory a adresáře v úložišti vytvářejí znovu a ztrácejí svou historii změn. Subversion musí k provádění těchto operací používat příkazy move ( movenebo mv) a copy ( ). copyJejich použití zachovává historii změn a umožňuje vyhnout se zbytečným operacím (zejména při práci s adresáři nebo dokonce větvemi souborového systému).
Na rozdíl od CVS jsou některé operace s pracovním kopírováním (jako je mazání a přesun souboru) zpracovávány samotným Subversion. Popsané a další rozdíly při práci se soubory pracovních kopií shrnuje následující tabulka ( commitvynechá operaci , kde je potřeba v obou případech):
| Úkon | CVS | podvracení | Poznámky |
|---|---|---|---|
| Mazání souboru | rm soubor cvs rm soubor |
svn rm file | soubor není nutné nejprve ručně smazat |
| Mazání souborů pomocí masky | rm * cvs rm soubor1 soubor2 ... |
svn rm * | soubory není třeba předem ručně mazat, není třeba vyjmenovávat všechny soubory |
| Přejmenovat/Přesunout | mv soubor1 soubor2 cvs rm soubor1 cvs přidat soubor2 |
svn mv file1 file2 | soubor není nutné přesouvat ručně , historie souboru je zachována |
| kopírování | cp soubor1 soubor2 cvs přidat soubor2 |
svn copy file1 file2 | soubor není nutné kopírovat ručně historie souboru je zachována (rozvětvená) |
| Přidání (vytvoření) adresáře | mkdir dir cvs přidat dir |
svn mkdir dir svn commit |
adresář nelze po přidání adresáře vytvořit ručněcommit |
| Přidání adresáře se soubory | cvs add dir cd dir cvs add file1 file2 |
svn add dir | adresář je přidán se soubory, které obsahuje |
| Přejmenování adresáře se soubory (žádné podadresáře) |
mkdir dir2 cvs add dir2 mv dir1/* dir2 cvs rm dir1/file1 dir1/file2 ... cvs add dir2/* |
svn mv dir1 dir2 | není třeba vytvářet a přidávat adresáře , není třeba ručně přesouvat soubory, není třeba vypisovat všechny soubory, historie souborů je uložena |
| Přejmenování větve souborového systému (adresáře se soubory a podadresáře) |
opakujte výše uvedené příkazy pro každou úroveň vnoření nebo každý podadresář [51] |
svn mv dir1 dir2 | viz výše nezávisí na počtu úrovní a adresářů |
V Subversion není nutné vytvářet tagy nebo používat datum/čas k řešení stavu úložiště, v jednoduchých případech (například pro získání verze po určitém odevzdání) bude snazší zadat požadované číslo revize .
Subversion je koncipován jako soubor knihoven rozdělených do několika úrovní. Každý z nich plní specifický úkol a umožňuje vývojářům vytvářet vlastní nástroje v závislosti na složitosti a úkolu.
fs Nejnižší úroveň; implementuje verzovaný souborový systém, který ukládá data. Repos Úroveň úložiště implementovaného v systému souborů. Na této úrovni je implementováno mnoho pomocných funkcí a podporuje také spouštění handlerů ( anglicky hooks ), tedy skriptů, které se spouštějí při výskytu události. Úrovně Fs a Repos dohromady tvoří rozhraní souborového systému . mod_dav_svn Poskytuje WebDAV / Delta-V přístup přes Apache 2. Ra Implementuje přístup k úložišti (místním i vzdáleným). Počínaje touto úrovní lze na úložiště odkazovat pomocí URL, tzn.Standardní klientská utilita Subversion, SVN, se konfiguruje pomocí proměnných prostředí a souborů INI vytvořených v domovském adresáři uživatele v podadresáři .subversion(umístění konfigurace v systémech Windows, v souborech nebo registru závisí na nastavení systému). V konfiguraci SVN také ukládá do mezipaměti SSL certifikáty, přihlašovací jména, hesla atd. (pokud to není v konfiguraci zakázáno) pro přístup k serverům Subversion.
Obsah adresáře .subversion:
Subversion nemusí vždy zpracovat přejmenování souborů správně, pokud se obsah souboru změní současně s přejmenováním. Problémy mohou také nastat, pokud soubor přejmenovaný v místní kopii upraví někdo jiný v úložišti. Některé z těchto problémů jsou opraveny ve verzi 1.5, ale toto řešení ještě není dokončeno. [53]
Operace slučování větví jsou také považovány za slabou stránku Subversion. Před verzí 1.5 museli uživatelé všechny takové operace sledovat ručně pomocí podrobných záznamů changelogu. Od verze 1.5 byla zavedena základní podpora pro automatické sledování sloučení, kterou vývojáři plánují vylepšit v dalších vydáních [54] . Subversion v současné době poměrně dobře podporuje běžné slučovací scénáře; ve složitějších případech jsou možné problémy. Doporučuje se [55] organizovat pracovní postup tak, aby se předešlo problematickým scénářům. Slučování přejmenovaných souborů a adresářů není podporováno.
Informace jednou umístěné v úložišti Subversion tam zůstanou navždy: soubor lze smazat v aktuální revizi, ale vždy je možné z úložiště získat jednu z předchozích revizí, ve kterých soubor existoval. Přestože uchovávání minulých revizí je ve skutečnosti účelem používání systémů správy verzí, někdy je nutné zcela odstranit informace z úložiště, které tam byly omylem umístěny. Subversion neposkytuje žádný nativní způsob, jak toho dosáhnout [56] ; jedinou možností je vytvořit výpis úložiště, zpracovat jej pomocí standardního nástroje svndumpfilter a poté úložiště z výpisu obnovit. Existují také programy třetích stran pro automatizaci tohoto procesu, ale v každém případě tato operace vyžaduje dočasné pozastavení přístupu k úložišti a zásah správce s dostatečně vysokými právy, aby bylo možné staré úložiště zcela vymazat a nahradit novým jeden.
|
název |
Popis |
Jazyk |
DB |
Licence |
webová stránka |
Aktualizace |
Verze |
|
nástroj založený na technologii Wiki |
Krajta |
SQLite, PostgreSQL, MySQL a MariaDB |
trac.edgewall.org Archivováno 8. dubna 2013 na Wayback Machine |
21.06.2017 |
1.2.2 | ||
|
další sledování chyb |
rubín |
MySQL, PostgreSQL, SQLite, Oracle. |
redmine.org Archivováno 27. dubna 2011 na Wayback Machine |
09.12.2018 |
4.0.0 | ||
|
nástroj pro vytváření a správu přístupu k úložištím, specializovaný na SVN |
PHP |
MySQL, SQLlite |
CeCill (licence kompatibilní s GPL). |
www.usvn.info Archivováno 12. května 2011 na Wayback Machine |
13.01.2012 |
1.0.6 | |
|
ViewVC |
bez správy uživatelů, nevyžaduje podporu DAV webovým serverem. |
Krajta |
MySQL |
Dvoučlenný Berkeley styl |
www.viewvc.org Archivováno 4. května 2011 na Wayback Machine |
02.12.2010 |
1.1.8 |
|
WebSVN |
rozhraní pro procházení k SVN |
PHP |
XML |
websvn.tigris.org Archivováno 12. června 2006 na Wayback Machine |
12. 10. 2010 |
2.3.2 | |
|
nástroj pro správu úložišť (vytváření, mazání, načítání a vyjímání; správa uživatelů a skupin) |
PHP |
MySQL nebo SQLite |
svnmanager.sourceforge.net Archivováno 30. dubna 2011 na Wayback Machine |
28.01.2012 |
1.09 | ||
|
Submin (MIT) |
nástroj pro správu úložišť a uživatelů, včetně správy řízení přístupu pro jednotlivé adresáře v úložišti |
Krajta |
MIT/X Archivováno 6. června 2011 na Wayback Machine |
24.12.2012 |
2.1 | ||
|
cSvn |
webové rozhraní pro prohlížení repozitářů Subversion |
C |
csvn.radix.pro Archivováno 16. března 2022 na Wayback Machine |
17. 11. 2020 |
0.1.3 |
| Systémy řízení verzí ( kategorie ) | |
|---|---|
| Pouze místní | |
| Klient-server | |
| Distribuováno | |
| Schémata URI | |
|---|---|
| Oficiální | |
| neoficiální | |