| felforgatás | |
|---|---|
| Típusú | központi verziókezelő rendszer [d] , Apache Foundation projekt [d] , ésnyílt forráskódú szoftver |
| Szerző | CollabNet [d] |
| Fejlesztő | Apache Software Foundation |
| Beírva | C [4] [5] , Python [4] , C++ [6] [7] és Java [6] [7] |
| Operációs rendszer | GNU/Linux [8] , Microsoft Windows [8] , macOS [8] és BSD [8] |
| Első kiadás | 2000. október 20. [1] |
| legújabb verzió |
|
| Olvasható fájlformátumok | SVN kiíratási formátum (v1) [d] , SVN kiíratási formátum (v2) [d] , SVN kiíratási formátum (v3) [d] és SVN kiíratási formátum (általános) [d] |
| Generált fájlformátumok | SVN kiíratási formátum (v1) [d] , SVN kiíratási formátum (v2) [d] , SVN kiíratási formátum (v3) [d] és SVN kiíratási formátum (általános) [d] |
| Engedély | Apache License 2.0 [9] |
| Weboldal | subversion.apache.org _ |
| Médiafájlok a Wikimedia Commons oldalon | |
A Subversion [10] (más néven " SVN " [11] ) egy ingyenes , központosított verziókezelő rendszer , amelyet hivatalosan 2004 -ben adott ki a CollabNet . 2010 óta a Subversion az Apache Software Foundation projektje, hivatalos neve Apache Subversion (bejegyzett védjegy [12] ).
A projekt célja a fejlesztés kezdetén az volt, hogy leváltsa [13] [14] az akkoriban elterjedt , mára már elavultnak számító Concurrent Versions System (CVS) [15] [16] [17] . A Subversion megvalósítja a CVS összes fő funkcióját, és mentes az utóbbi néhány hiányosságától.
A Subversion-t még mindig használják néhány nyílt forráskódú közösség (beleértve azokat is, amelyek korábban a CVS -t használták ), de szinte minden nagyobb projekt átkerült a DVCS -re . A Subversion utolsó felhasználói között a nyílt projektek között továbbra is a FreeBSD , de bejelentették a Gitre [18] , és például a Free Pascalra való átállást is . A Subversion-t elég régóta használják olyan ismert projektek, mint az Apache , GCC , FFmpeg , LLVM . A Subversion-t magánprojektekben és a vállalati világban is használják, de nehéz felmérni, hogy milyen széles körben. A Subversion tárhelyszolgáltatását , beleértve a nyílt forráskódú projekteket is, a SourceForge.net , a Tigris.org , a Google Code és a BountySource népszerű hosting projektjei is biztosítják .
2007- ben a Forrester elemzőcég a Subversion-t "az önálló szoftverkonfiguráció-kezelés (SCM) kategória egyedüli vezetőjének, valamint a szoftverkonfiguráció és -változáskezelés (SCCM) kategóriában erős közreműködőnek" minősítette , amikor összehasonlítja a különféle szoftverek előnyeit és hátrányait. rendszerek . [19]
A Linux -csomagok – Debian [20] és Ubuntu [21] disztribúciók – használatára vonatkozó statisztikák szerint a Subversion aktív felhasználóinak száma 2010 körül érte el a csúcsot, és 2016 óta csökkenni kezdett. Azonban még mindig több projekt használja a Subversion-t, mint a CVS -t , a Mercurialt és a Bazaart ( 2019 augusztusában ).
A hivatalos dokumentációt [22] az O'Reilly Media által kiadott könyv helyezi el , amely szabadon hozzáférhető [23] és a szerzők az SVN új verzióinak megjelenésekor adják hozzá. Számos nyelvre, köztük oroszra is kiadja fordításait, de annak ellenére, hogy a könyv angol nyelvű változatai már az 1.8-as és az 1.7-es verziókat is leírják, csak orosz nyelvű könyvek vannak, amelyek az 1.4-ig terjedő verziókat írják le [24] .
A Subversion fejlesztése 2000 -ben kezdődött a CollabNet kezdeményezésére és anyagi támogatásával. A projekt kezdeményezői egy ingyenes verziókezelő rendszert szerettek volna létrehozni, amely alapvetően hasonló a CVS-hez, de mentes a hibáktól és a kellemetlenségektől . Abban az időben ebben az osztályban nem léteztek legjobb ingyenes licenccel rendelkező programok, a CVS volt a de facto szabvány a szabad szoftverfejlesztők körében. A Subversion fejlesztői azzal a szándékkal, hogy a már bevált koncepciókat kihasználva leegyszerűsítsék a fejlesztést, ugyanakkor sok CVS-felhasználó számára megkönnyítik az új rendszerre való átállást. [25]
Főbb események a Subversion fejlődéstörténetében.
A Subversion egy központosított rendszer (ellentétben az olyan elosztott rendszerekkel, mint a Git vagy a Mercurial ), ami azt jelenti, hogy az adatokat egyetlen adattárban tárolják. A tárhely lehet helyi lemezen vagy hálózati szerveren .
A Subversionban végzett munka nem sokban különbözik a többi központosított verziókezelő rendszerben végzett munkától. Az ügyfelek átmásolják a fájlokat a tárolóból, hogy helyi munkapéldányokat hozzanak létre, majd módosítsák a munkapéldányokat, és végrehajtsák a változtatásokat a tárolóban. Egyszerre több ügyfél is hozzáférhet a tárhelyhez. A Subversion elsősorban a másolás-módosítás-egyesítés modellt használja a fájlokon való együttműködéshez . Ezenkívül a nem egyesíthető fájlok (különféle bináris fájlformátumok) esetén használhatja a zárolás-módosítás-feloldó modellt .
Az új verziók mentésekor delta tömörítést alkalmazunk : a rendszer különbségeket talál az új és az előző verzió között, és csak azokat írja ki, elkerülve az adatok megkettőzését.
WebDAV hozzáférés használatakor az átlátható verziókezelés is támogatott – ha bármelyik WebDAV kliens megnyílik írásra, majd elment egy hálózati megosztáson tárolt fájlt, akkor automatikusan új verzió jön létre.
A Subversion két lehetőséget kínál a tárolók rendszerezésére [40] . Az első típusú adattárak a Berkeley DB alapú adatbázisok tárolására szolgálnak, a második típusú tárolók speciális formátumú közönséges fájlok (az adathozzáférés saját könyvtáraik segítségével szerveződik, harmadik féltől származó adatbázisok használata nélkül). A Subversion fejlesztői a tárolást gyakran "fájlrendszernek" nevezik, ezért a második típust FSFS-nek hívják, ami egy (verziós) fájlrendszert ( angol fájlrendszer ) jelent a (normál) fájlrendszer tetején.
Mindkét típusú adattár megfelelő rendszerezés esetén kellő megbízhatóságot biztosít [41] (a Berkeley DB fájlzárakat használ, így egyes hálózati fájlrendszereken nem használható, amelyek nem támogatják a zárolást), mindegyiknek megvannak a maga előnyei és hátrányai. Úgy gondolják, hogy az FSFS-t könnyebb megfelelően konfigurálni, kevesebb figyelmet igényel a rendszergazdától. Ezenkívül az 1.4-es kiadás előtt a Berkeley DB-t használó adattárak bizonyos feltételek mellett úgynevezett ékelt állapotba kerülhetnek ; a működőképesség helyreállításához rendszergazdai beavatkozásra volt szükség.
Az 1.2-es kiadástól kezdve alapértelmezés szerint az FSFS-t használják az új tárolókhoz. Az 1.8-as kiadással a Berkeley DB használata elavulttá vált [37] . Előfordulhat, hogy a jövőbeli kiadásokban hozzáadott új szolgáltatások nem működnek a Berkeley DB-t használó kiszolgálókon. A Berkeley DB támogatása a jövőben megszűnhet.
A Subversion a következő módokat kínálja a tároló eléréséhez:
Mindezek a módszerek mindkét típusú adattárral (FSFS és Berkeley DB) használhatók. Egyszerre különböző módszerek használhatók ugyanahhoz a tárolóhoz.
A felhasználó szemszögéből a Subversion adattár egy "kétdimenziós" fájlrendszer . A lerakatban lévő objektumokat ( fájlok és könyvtárak ) két " koordináta " azonosítja: egy név és egy változatszám . Más szavakkal, a tárház pillanatképek (revíziók) tömbje fájlok és könyvtárak fájáról, a verziószámmal indexelve. Minden ilyen pillanatkép egy normál (egydimenziós) fájlrendszer.
Ha egy objektum konkrét revízióját kell jelezni, akkor a következő alakú bejegyzést használjuk: имя@ревизия, például /main.c@29 a /main.c fájl a 29-es revízióban. A revíziónak a név tisztázására használt ilyen jelzését peg - nek nevezzük. revízió .
ábrán. Az 1. ábra a fájlrendszer grafikus ábrázolását mutatja: a függőleges tengely a névkészletnek, a vízszintes tengely a revíziók halmazának felel meg.
FájlnevekEgy fájlrendszer objektum neve a Subversionban ugyanazok a szabályok szerint alakul, mint a UNIX-szerű operációs rendszerekben: csak egy gyökérkönyvtár van, az elérési út elemeket perjel („/”) választja el egymástól. A fájlrendszer-objektumok fájlok és könyvtárak (valamint szimbolikus hivatkozások , amelyeket a rendszer normál fájlokból emulál az attribútum beállításával svn:special).
VerziószámokA Subversion verziószáma egy természetes szám (vagy 0 a legelső revízió esetén), amely a lerakat állapotszámára vonatkozik, amint az abban lévő adatok változnak. Minden sikeres véglegesítés pontosan egy új revíziót hoz létre a lerakatban, így az N. revízió a lerakat állapota az N. véglegesítés után.
A Subversionban a revízió nem egy fájl, hanem a teljes tár egészének állapotát jellemzi. Például a 32-es változat (az ábrán pontozva) négy fájl és két könyvtár állapota, amelyek akkoriban léteztek a lerakatban.
A revíziószám analóg az idővel abban az értelemben, hogy az alacsonyabb revíziószámok a repository korábbi állapotainak, a magasabb verziószámok pedig a későbbieknek felelnek meg.
A revíziószám egyfajta időbélyegnek tekinthető az adattár történetében. Ezenkívül minden revíziószámnak van egy abszolút értéke, amely a revízió végrehajtásának idejéhez van társítva ( tulajdonság svn:date ). A revíziószám megadása azonban kényelmesebb, mint az idő megadása, mivel az időzónákkal nem lehet összetéveszteni, a számbevitel rövidebb, a revíziószám pedig nem módosítható.
Működési és alapvető átdolgozásokA változatszámot két különböző kontextusban használják :
Egy revíziót operatívnak nevezünk, ha megadja azt a revíziót vagy a revíziók tartományát, amelyre a műveletet alkalmazni kell , például:
svn log -r 199:230 http://some.pathEbben a példában a parancs svn loga revíziók tartományára kerül végrehajtásra 199:230, amely az online változatok tartománya.
Azonban csak a fájlnév és az online változat megadása néha félreérthetően a lerakatobjektumokra mutathat. ábrán látható helyzetben például. 2, kétértelműség adódik a következő parancs futtatásakor:
svn log -r 29:33 http://some.path/bar.txtA parancs megadja az online revíziók tartományát ( 29:33), de az ábrán kékkel és zölddel kiemelt területek ugyanúgy tekinthetők a /bar.txtrevíziós tartományban lévő fájl előzményeinek 29:33. Ilyen esetekben meg kell adni a pivot revíziót is a kétértelműség feloldása érdekében. Az alapváltozat a fájlrendszer-objektum URL -címe mellett megadott változatszám (a " URL@ревизия" jelöléssel). A név az angol peg szóból származik , amelyet "rúdnak" vagy "pegnek" lehet fordítani. A pivot revízió megjelöli az állapotok láncát, amelyhez a megadott pár tartozik URL@ревизия, és így egyedileg azonosítja azt a tárolóobjektumot, amelyre a parancsot alkalmazni kell. Az alábbi példában az első parancs az ábrán kékkel kiemelt történetet, a második parancs pedig a zölddel kiemelt történetet nyomtatja ki:
svn log -r 29:33 http://some.path/file.txt@32 svn log -r 29:33 http://some.path/bar.txt@34Az érdekelt tárgy legfrissebb állapotát kell megadni alaprevízióként. Ennek az az oka, hogy az állapotláncot egyedileg „vissza”, de nem „előre” követik. Például a http://some.path/foo.txt@31 pivot változatú URL két állapotlánchoz tartozik (zölddel és szürkével kiemelve). E két lánc közül a megadott URL a szürke láncot címezi meg, vagyis amikor az alapváltozattól "előre" lép, a másolási műveletek figyelmen kívül maradnak.
Műveletek a fájlrendszerenA Subversion lerakatában [42] található fájlrendszer-objektumokon a következő műveletek hajthatók végre (lásd 1. ábra). A zárójelek a művelet rövid elnevezését jelzik a parancs jelölésében svn status.
A munkapéldány a Subversion kliensprogram által létrehozott adattárból származó adatrész helyi másolata, amely magán az adatokon kívül néhány szolgáltatási információt is tartalmaz (rejtett könyvtárak néven .svn). A szervizinformációk a munkapéldány megfelelő működéséhez szükségesek; a szerviz adatokon nem lehet változtatni. Az adattárból munkapéldányként lehívható legkisebb adategység egy könyvtár. Előfordulhat, hogy egy könyvtár tartalma nem bontható ki teljesen: például az egyes fájlok vagy alkönyvtárak kizárhatók. Nem lehetséges azonban egyetlen fájlt sem kivenni a tárolóból munkapéldányként.
A Subversion 1.6 és korábbi munkapéldányok bármely alkönyvtára egyben teljes munkapéldány is, mert minden könyvtár tartalmazza a háztartási adatait (könyvtárak .svn). Az 1.7-es verzió óta minden munkapéldánynak csak egy könyvtára .svnvan a könyvtárának gyökerében.
A munkapéldány önálló abban az értelemben, hogy a Subversion nem tárol a munkapéldányhoz kapcsolódó adatokat azon kívül. Ezért egy munkapéldány birtokában több másolatot is készíthet egyszerű másolással, hálózati forgalom ráfordítása nélkül.
A munkapéldány szolgáltatási könyvtáraiban többek között az úgynevezett tiszta másolat ( eng. pristine copy ) tárolódik - a munkapéldány fájljai változatlan formában, ahogyan azokat a repository-ból kivonták (svn esetében ez egy BASE nevű változat). A tiszta másolat lehetővé teszi a helyi módosítások gyors megtekintését és visszaállítását anélkül, hogy hozzáférne a tárhoz. A lemezen lévő munkapéldány mérete azonban körülbelül kétszer akkora (adat + adatok tiszta másolata), mint magának az adatnak a mérete. Ez a megközelítés annak a ténynek köszönhető, hogy a lemez erőforrások olcsóbbak és könnyebben hozzáférhetők, mint az adathálózati erőforrások .
Általában a munkapéldány létrehozása az első és szükséges lépés a helyi változtatások végrehajtásához, mert csak a munkapéldányon végrehajtott módosítások véglegesíthetők a lerakatban. Ez alól kivételt képeznek azok a műveletek, amelyek munkapéldány létrehozása nélkül közvetlenül végrehajthatók a tárolón.
TranzakciókA Subversionban a tárolás az ACID tulajdonságkészletből származó atomitási és izolációs tulajdonságokkal rendelkező tranzakciók formájában szerveződik . Így a verziókezelő rendszer garantálja a repository integritását, konzisztenciáját és bármikor elérhetőségét.
Ezek a tulajdonságok nem garantáltak a Subversion munkapéldányainál – a tárolókkal ellentétben lehet köztes vagy zárolt állapotban, ha összeomlik vagy megszakad (vagyis egy paranccsal vissza kell állítani, svn cleanupvagy újra létre kell hozni a folytatás előtt).
Helyi és távoli parancsűrlapokAz összes Subversion kliens parancs a következő csoportokba osztható:
Formálisan a Subversion nem ír elő semmilyen korlátozást a projekt fájlszerkezetére vonatkozóan – ez bármi lehet a fájlrendszerben lévő objektumok elnevezésére vonatkozó szabályok keretein belül. Vannak azonban irányelvek, amelyek megkönnyítik az ágakkal és címkékkel való munkát. A legegyszerűbb esetben ajánlatos legalább három alkönyvtárat létrehozni a tároló gyökérkönyvtárában:
/. trunk branches tagsA projekt teljes fájlstruktúráját (a fő fejlesztési sort) az alkönyvtárnak kell tartalmaznia trunk, az alkönyvtárnak tartalmaznia kell a projekt ágait és a címkéket . Például a következő lerakatkönyvtár-struktúra: branchestags
/. trunk branches branch_1 tags tag_1 tag_2
feltételezi, hogy a projektnek ( trunk) egy „ ” ága és két „ ” és „ ” branch_1címkéje van . Ezen könyvtárak mindegyike ( , , és ) tartalmazza a projekt megfelelő verziójának másolatát. tag_1tag_2trunkbranch_1tag_1tag_2
Ha több (al)projekt van a repositoryban, akkor minden (al)projekthez a következő alkönyvtár-struktúra jön létre:
/. project1 trunk branches tags project2 trunk branches tagsVagyis a gyökérkönyvtár projektkönyvtárakat tartalmaz, és mindegyiknek megvan a saját trunk, branches, tags, amely csak ehhez a projekthez kapcsolódik. A leírt tárolási címtár-struktúrák csak példák, a gyakorlatban a tárolást az adott esetnek leginkább megfelelő módon lehet megszervezni. [43] [44]
Több projekt tárolásának másik módja több adattár létrehozása. Az egymással semmilyen kapcsolatban nem álló projekteket különböző tárhelyekben kell elhelyezni, mivel a másolási, áthelyezési és összevonási műveletek nem hajthatók végre a tárolók között. Szükség esetén több lerakat összevonható egybe a revíziók előzményeinek megőrzésével ( svnadmin loadparaméteres paranccsal történő importálással --parent-dir).
ÁgakA Subversion egy "fájl" modellt használ (ugyanaz, mint a Perforce [45] ) az elágazások és címkék megvalósításához, azaz az ág csak egy könyvtár (könyvtár helyett egyetlen fájlból is készíthet elágazást). A parancs új ágat hoz létre svn copy. Elágazás bármely lerakatkönyvtárban létrehozható, de célszerű követni a fent leírt konvenciókat az új ágak létrehozására vonatkozóan. Az ágakkal kapcsolatos további információkért lásd: Elágazás és összevonás .
CímkékA címke létrehozása szintén a paranccsal történik svn copy, azaz technikailag ugyanaz, mint egy elágazás. Az egyetlen különbség a felhasználás módjában van: feltételezzük, hogy senki nem fogja megváltoztatni a címkén szereplő adatokat (módosításokat végrehajtani rajta). Például a 2. ábrán. 1 címke a 29-es változatban készült: a 27-es változat könyvtára /trunka név alatt másolva /tags/R1. Ha most nem változtatja meg a könyvtár adatait /tags/R1, akkor az örökre a címtár pontos másolata marad /trunk@27, vagyis egy címke lesz .
A Subversionban használt címkék fogalma eltér a többi verzióvezérlő rendszerben használt címkék koncepciójától. A címke általában egy szimbolikus név, amely egy fájlkészletet és azok állapotát szólítja meg. A Subversionban egy címke fájlkészletet és azok állapotát másolja . A Subversion címkéinek másolása megvannak a maga előnyei és hátrányai.
Előnyök:
Hibák:
A Subversion egyik fontos tulajdonsága a tulajdonságok, azaz a név = érték szövegpárok támogatása , amelyek az áruházban lévő objektumokon állíthatók be. A tulajdonságok két különböző környezetben használatosak: fájlrendszer-objektumokhoz és változatokhoz.
A fájlrendszer-objektumok tulajdonságaiA tárolóban lévő minden fájlhoz vagy könyvtárhoz hozzá lehet rendelni egy tulajdonságkészletet. A tulajdonságváltozások ugyanúgy tárolódnak az előzményekben, mint a fájlrendszer módosításai. A felhasználók bármilyen néven beállíthatnak tulajdonságokat; van egy előre meghatározott segédprogram-tulajdonságkészlet is, amelyeket a Subversion ügyfélprogram használ (a segédprogram-tulajdonságok neve előtt az "svn:" szerepel).
Fájl tulajdonságai svn:executable Futtathatóvá teszi a fájlt (munkamásolatokhoz a UNIX család operációs rendszerei alatt ). svn:mime-type Tárolja a fájl MIME típusát. Befolyásolja a fájlkülönbségeket mutató parancsok működését és az egyesítési módosításokat (egyesítést). svn:keywords Kulcsszavak listája ( eng. kulcsszavak ), amelyeket a fájlban a megfelelő értékekkel helyettesítünk. Ahhoz, hogy a helyettesítés megtörténjen, a kulcsszónak jelen kell lennie a fájlban $keyword$. A fájl értékeinek automatikus frissítésére szolgál, amelyek verzióról verzióra változnak (például a verziószám). svn:eol-style Megadja a szövegfájlban lévő sorvégi ( EOL ) karakterek konvertálására vonatkozó szabályt . Olyan esetekben használatos, amikor a fájlnak meghatározott EOL karaktertípussal kell rendelkeznie. Általában "natív" használatos – ebben az esetben a sorvégi karakterek típusa megegyezik az operációs rendszerben elfogadott típussal, amelyben a munkapéldányt létrehozzák. svn:needs-lock Azt jelzi, hogy a fájl csak olvasható lesz, amikor lekéri a tárhelyről. Ezt a tulajdonságot a blokkoló mechanizmussal együtt kell használni . A fájl írásának megtagadása emlékeztet arra, hogy a fájl zárolását a szerkesztés előtt szerezze be: a zárolás megszerzésekor a Subversion kliensprogram automatikusan írhatóvá teszi a fájlt (a zárolás újbóli feloldásával a fájl nem módosítható). A zárak a tulajdonság beállítása nélkül is használhatók. Ez azonban nem ajánlott, mert fennáll annak a veszélye, hogy egy másik felhasználó elkezdheti szerkeszteni a zárolt fájlt, és ez csak a változtatások végrehajtása után derül ki. svn:special A tulajdonságot nem a felhasználók állíthatják be vagy módosíthatják. Jelenleg szimbolikus hivatkozások tárolására szolgál a tárolóban. Amikor egy szimbolikus hivatkozást adunk egy tárhoz, egy fájl jön létre a tárolóban a svn:special. Amikor ezt a fájlt kiveszi egy UNIX - szerű rendszeren, a Subversion kliensprogram visszaalakítja hivatkozássá. svn:mergeinfo Információkat tárol arról, hogy mely útvonalak egyesültek ebbe a fájlba. A tulajdonságot az 1.5-ös verzióban vezették be, az egyesítés nyomon követésére szolgál . Ez egy fájlnév: revision_range formátumú karakterláncok halmaza . Itt a fájlnév annak a fájlnak vagy könyvtárnak a teljes neve (a lerakat fájlrendszerének gyökérkönyvtárának elérési útjával), amelyből a revíziók meghatározott tartománya egyesült. A sorok automatikusan frissülnek az egyesítési műveletek során; A későbbi egyesítéseknél a Subversion figyelembe veszi a korábban hozzáadott sorokat, elkerülve ezzel ugyanazon változtatások ismételt összevonását. Nem ajánlott manuálisan módosítani a tulajdonságot – ez megszakíthatja az egyesítés nyomon követési mechanizmusát.svn:mergeinfo Könyvtár tulajdonságai svn:ignore Azon fájl- és könyvtárnévminták listája, amelyeket a Subversion ügyfélprogram figyelmen kívül hagy ebben a könyvtárban. Ez a tulajdonság hasonló a .cvsignoreCVS-ben lévő fájlhoz . Általános szabály, hogy a tulajdonság úgy van beállítva, hogy az ügyfélprogram „nem látja” a különböző programok által automatikusan létrehozott fájlokat és könyvtárakat, amelyeket nem szabad verziózni (például objektumfájlok , ideiglenes fájlok stb.). Ez a tulajdonság nem vonatkozik az alkönyvtárakra. svn:externals Lehetővé teszi egy könyvtárkészlet automatikus kibontását egy munkapéldányba az URL -címük megadásával (akár egy másik tárolóból is). svn:mergeinfo Ugyanaz, mint a fájloknál . Revízió tulajdonságaiA második típusú objektum, amelyhez tulajdonságok léteznek, maguk a revíziók. Ebben az esetben a tulajdonságnevek is bármiek lehetnek; néhány "svn:" előtaggal ellátott tulajdonság különleges jelentéssel bír. A revíziók és a fájlrendszer-objektumok tulajdonságai között az a különbség, hogy az előbbire a verzióelőzmény fogalma nem alkalmazható (mivel egy változathoz egy adott tulajdonságérték van hozzárendelve). Más szavakkal, a revízió tulajdonságai módosíthatók, de a régi érték elveszik. Alapértelmezés szerint a változat tulajdonságainak módosítása le van tiltva; hogy az adminisztrátor létrehozzon egy szkriptet ( eng. hook ) az esemény kezelésére pre-revprop-change.
svn:date A revízió létrehozásának dátuma és időpontja. svn:author Annak a felhasználónak a neve, aki végrehajtotta az ebben a változatban szereplő változtatásokat. svn:log Az ebben a revízióban végrehajtott változtatások leírása (a felhasználó által a változtatások végrehajtásakor megadott szöveg).A revízió tulajdonságait általában csak az adattár adminisztrátora módosítja a hibás adatok kijavítása érdekében. Például, ha a felhasználó elfelejtett szöveges leírást megadni a változtatások végrehajtása során, akkor a rendszergazda létrehozhatja ezt a leírást a szerkesztésével svn:log.
Egy tipikus munkafolyamat-iteráció Subversionnal a következő lépéseket tartalmazza.
Az elágazás fontos szempont a verziókezelő rendszerek működésében, mivel a tipikus verziókezelési technikák [47] (legalábbis a szoftverfejlesztésben ) elágazások használatát foglalják magukban. A Subversion meglehetősen fejlett elágazási és egyesítési képességekkel rendelkezik (azonban nem támogatja az átnevezett fájlok és könyvtárak egyesítését).
ábrán. A 3. ábra hagyományosan egy példát mutat be az ágak fejlődésére az adattárban. A zöld szín a projektfejlesztés fő vonalát mutatja ( eng. mainline, trunk ), sárga - ágak, kék - címkék, bíbor - egy olyan ág, amelynek fejlesztése megszakadt. A piros nyilak az összevonási változásokat mutatják.
Elágazások létrehozásaA parancs egy új ágat (valamint egy címkétsvn copy ) hoz létre, amely másolatot hoz létre a tárolóban a forrás revíziós előzményeinek öröklésével ( A+ művelet ). Mindig a parancs "távoli" formáját kell használnia ágak létrehozásához svn copy, például:
svn másolat http://.../trunk/dir http://.../branches/branch_name -m "A könyvtár ágának létrehozása"Az eredményül kapott másolat egy ág (vagy egy címke, attól függően, hogy hogyan dolgozik vele) lesz. A jövőben az ágon végrehajtott módosítások végrehajthatók azon a forráson, amelyből az ágat létrehozták, a változtatások ilyen terjesztését összevonásnak nevezzük .
A Subversion másolási műveletei olcsók ( eng. cheap copy ), azaz kis fix idő- és lemezterületet igényelnek. A tároló úgy van kialakítva [48] , hogy a másolás során ne az adatok duplikálódnak, hanem a forrásra mutató hivatkozás jöjjön létre (hasonlóan a hard linkhez ), azonban ez a mechanizmus tisztán belső – a felhasználó oldaláról nézve. nézetben egy másolat létrehozása történik. Az elágazás nagy hatékonyságának köszönhetően az elágazások tetszőleges gyakorisággal hozhatók létre (azonban az összevonás - az elágazás szükséges kiegészítése - lassabb a Subversionban, mint más modern verzióvezérlő rendszerekben).
Munka ágakkalÁltalánosságban elmondható, hogy az ágon végzett munka nem különbözik a fő fejlesztési vonalon ( törzs ) végzett munkától. Konkrét parancsok csak az egynél több ágat érintő tevékenységekhez szükségesek. Ezek a parancsok a következőket tartalmazzák (az ág létrehozása parancson kívül svn copy):
Az ágakkal való munkavégzés teljes ciklusa általában a következő lépéseket tartalmazza:
Az összevonás a Subversionban egy másik (vagy ugyanazon) ágon végrehajtott változtatások halmazának egy ágára történő alkalmazása. Az egyesítés végrehajtásához egy parancsot kell használnia svn merge - ez egy változáskészletet alkalmaz egy munkapéldányra; akkor végre kell hajtania a változtatásokat ( svn commit).
A terminológia összevonása kissé zavaró. Az összevonás kifejezés nem teljesen pontos, mivel az ágak összevonásáról nincs szó . Ezenkívül nem szabad egyenlőségjelet tenni az egyesítés és a parancs között: egyrészt az összevonáshoz (a mellett ) konfliktusfeloldást és véglegesítést kell végrehajtania, másrészt az alkalmazás nem korlátozódik az összevonásra. svn mergesvn mergesvn merge
Az svn merge parancs egyéb felhasználási módjaiA parancs svn mergenem csak egyesítésre használható. Valójában a parancs megváltoztatja a munkapéldányt a tárolóban lévő két könyvtár vagy fájl különbségével , ezért ez svn mergeegy univerzális eszköz a változtatások átvitelére. Íme néhány példa a parancs használatára svn merge:
A parancs egy tároló létrehozására szolgál svnadmin create. Ez a művelet egy üres tárolót hoz létre a megadott könyvtárban.
Az alábbiakban a Subversion és a CVS rendszerek paramétereinek összehasonlítása látható, mivel a Subversion pontosan a CVS továbbfejlesztéseként van pozicionálva. Az összehasonlítás csak azokra a paraméterekre vonatkozik, amelyekben ezek a rendszerek különböznek egymástól. Összességében a Subversion minden tekintetben felülmúlja a CVS-t, kivéve a hagyományos értelemben vett címkéket (vagyis a fájlrendszer-objektumokat megszólító címkéket).
| Paraméter | felforgatás | CVS |
|---|---|---|
| Képességek | ||
| Katalógusok | Nem csak a fájlok, hanem a könyvtárak verzióit is követi. | A címtárverziókat nem követi nyomon a rendszer, vagyis a címtárszerkezet ugyanaz (az, ami jelenleg a tárolóban létezik) minden revíziónál és minden ágnál. Ha megváltoztatjuk a könyvtárszerkezetet, akkor a régi állapotok kibontásakor a fájlok helyes (régi) revízióit kapjuk, de rossz (a kibontáskor meglévő) könyvtárstruktúrában. |
| Tranzakciók | A többfájlos véglegesítések atomitása. | Az atomitás csak az egyfájlos véglegesítés szintjén van. Valójában a több fájl módosításának végrehajtása az egyes fájlokra vonatkozó véglegesítések sorozatára bontható. Ha egy ilyen véglegesítési sorozat megszakad, akkor a fájlok egy része véglegesen marad, míg mások nem véglegesítve maradnak. |
| Változáskészletek | Változáskészletek támogatottak . _ | A módosításkészletek nem támogatottak. |
| Fájlnév módosítások | Támogatja a fájlok és könyvtárak másolását, áthelyezését és átnevezését a változástörténet elvesztése nélkül. | Fájlok másolása, áthelyezése, átnevezése során az új nevű fájlnak nincs előzménye, vagyis teljesen megszakad a kapcsolat a régi névvel és annak verzióelőzményeivel. Ugyanez vonatkozik a könyvtárban lévő fájlokra, amikor módosítja a nevét [49] . |
| tulajdonságait | Minden fájlhoz és könyvtárhoz tetszőleges tulajdonságkészlet tartozhat, amely egy névből és egy értékből áll. A tulajdonságok szintén verziókezelés alatt állnak. | A tulajdonságok nem támogatottak. |
| Zárak | Az opcionális fájlzárolás támogatott (az 1.2-es verzió óta). | A zárolások nem támogatottak, de létezik egy hasonló mechanizmus, az úgynevezett nyomkövetés . |
| ágak | Az ágak ( elágazás , lásd Szójegyzék ) az elérési út térben vannak megvalósítva. Ez azt jelenti, hogy egy elágazás létrehozásához a könyvtár átmásolódik (a másolat lesz az ág). Az ilyen másolatok készítése gyors és nem erőforrásigényes művelet, mivel az adatok nem duplikálódnak , helyette egy új verzió kerül rögzítésre, amely csak a fájlok helyében tér el az előzőtől. | Az ágak a "harmadik dimenzióban" valósulnak meg. Ez azt jelenti, hogy egy ágon lévő fájl három paraméterrel van megcímezve: elérési út a fájlrendszerben, revízió (vagy a revízió jelzésének más módja, például idő), ág neve . |
| Címkék | Nincsenek címkék ( tag , lásd szótár ) mint olyanok. Ehelyett egy könyvtárhierarchiát használnak – külön könyvtár jön létre a címkéhez (valamint az ághoz). A címke egy olyan ág, amelyen a megállapodás szerint nem történik további módosítás. A címke a fájlok és könyvtárak címkézett állapotának másolata . | A címkék támogatottak. A címke a fájlok címkézett állapotára vonatkozik. |
| Hatékonyság | ||
| Kliens-szerver csere | A kliens és a szerver közötti verziófrissítések csak a fájlkülönbségeket továbbítják, ami jelentősen csökkentheti a hálózati forgalmat. | A különbségek átkerülnek a szerverről a kliensre, és a teljes objektum átkerül a kliensről a szerverre. |
| Binárisok | Egyformán hatékonyan működik szöveges és bináris fájlokkal is . | A bináris fájlokkal való munka kevésbé hatékony: minden új verzió teljes egészében a lerakatban tárolódik. |
| Elágazások és címkék létrehozása | Kis fix időt és lemezterületet igényel. | Az időköltségek magasak (az érintett fájlok számától függően). Az ágak és címkenevek redundánsan tárolódnak (minden érintett fájlban). |
| Rezsi munkapéldányban | A munkapéldány szolgáltatási könyvtárai tiszta másolatot tárolnak. Ezért a helyi változtatások böngészése és visszagörgetése gyors (anélkül, hogy a tárhelyre kerülne), de a lemezen lévő munkapéldány mérete körülbelül kétszer akkora, mint magának az adatnak a mérete. | A tiszta másolat nem kerül tárolásra, a munkapéldány mérete megközelítőleg megegyezik az adatok méretével. Ennek eredményeként a helyi módosítások megtekintési és visszaállítási műveletei hozzáférést igényelnek a lerakathoz, és lassúak. |
| Memóriafogyasztás a szerveren | Kevesebb [50] . | Több. |
Létezik egy cvs2svn program, amely egy CVS-tárat kész Subversion-tárrá (vagy git -tárolóvá ) vagy szövegkiírattá konvertál, amelyet azután a tárolóba importálhatunk a svnadmin. Ezzel egyidejűleg a cvs2svn elmenti a CVS repository-ban található összes információt: elágazásokat, címkéket, változásleírásokat, szerzők neveit, véglegesítési dátumokat. Ezen túlmenően, a különböző fájlokban végrehajtott változtatások egy változatba konvertálódnak.
Használati különbségek Fájlkezelési különbségekA CVS-ben a fájlok és könyvtárak áthelyezése (átnevezése) és másolása egy objektum új névvel való újbóli hozzáadásával és (áthelyezéskor és átnevezéskor) a régi objektum törlésével történik. Ezzel a munkával a lerakatban lévő fájlok és könyvtárak újból jönnek létre, és elvesztik változástörténetüket. A Subversionnak a move ( movevagy mv) és a copy ( copy) parancsokat kell használnia ezeknek a műveleteknek a végrehajtásához. Használatuk megőrzi a változtatások előzményeit, és lehetővé teszi a szükségtelen műveletek elkerülését (főleg, ha könyvtárakkal vagy akár fájlrendszer-ágakkal foglalkozunk).
A CVS-től eltérően néhány működő másolási műveletet (például egy fájl törlését és áthelyezését) maga a Subversion kezeli. A munkamásolat-fájlokkal való munkavégzés során leírt és egyéb különbségeket a következő táblázat foglalja össze (a műveletet commit, ahol mindkét esetben szükséges, kihagyjuk):
| Művelet | CVS | felforgatás | Megjegyzések |
|---|---|---|---|
| Fájl törlése | rm fájl cvs rm fájl |
svn rm file | a fájlt nem kell először manuálisan törölni |
| Fájlok törlése maszkkal | rm * cvs rm fájl1 fájl2 ... |
svn rm * | a fájlokat nem kell előzetesen kézzel törölni, nem kell minden fájlt felsorolni |
| Átnevezés/Áthelyezés | mv fájl1 fájl2 cvs rm fájl1 cvs fájl hozzáadása2 |
svn mv file1 file2 | a fájlt nem kell kézzel áthelyezni, a fájlelőzmények megmaradnak |
| másolás | cp file1 file2 cvs add file2 |
svn copy file1 file2 | a fájlt nem kell manuálisan átmásolni, a fájltörténet megmarad (elágazva) |
| Könyvtár hozzáadása (létrehozása). | mkdir dir cvs add dir |
svn mkdir dir svn commit |
a könyvtárat nem lehet manuálisan létrehozni, miután a könyvtár hozzáadása szükségescommit |
| Könyvtár hozzáadása fájlokkal | cvs add dir cd dir cvs add file1 file2 |
svn add dir | a könyvtár hozzáadódik a benne lévő fájlokkal |
| Könyvtár átnevezése fájlokkal (nincs alkönyvtár) |
mkdir dir2 cvs add dir2 mv dir1/* dir2 cvs rm dir1/file1 dir1/file2 ... cvs add dir2/* |
svn mv dir1 dir2 | nincs szükség könyvtárak létrehozására és hozzáadására, nem kell manuálisan áthelyezni a fájlokat , nincs szükség az összes fájl listázására . A fájltörténet mentésre kerül |
| A fájlrendszer egy ágának átnevezése (könyvtárak fájlokkal és alkönyvtárak) |
ismételje meg a fenti parancsokat minden egyes beágyazási szinthez vagy alkönyvtárhoz [51] |
svn mv dir1 dir2 | lásd fent nem függ a szintek és könyvtárak számától |
A Subversionban nem szükséges címkéket létrehozni vagy dátumot/időt használni az adattár állapotának kezelésére, egyszerű esetekben (például egy bizonyos véglegesítés utáni verzió beszerzéséhez) egyszerűbb lesz megadni a szükséges verziószámot .
A Subversion több szintre osztott könyvtárak halmazaként készült. Mindegyikük egy adott feladatot hajt végre, és lehetővé teszi a fejlesztők számára, hogy saját eszközöket hozzanak létre, a bonyolultságtól és a feladattól függően.
fs A legalacsonyabb szint; verziójú fájlrendszert valósít meg, amely adatokat tárol. Repos A fájlrendszerben megvalósított tárhely szintje. Ezen a szinten számos segédfunkciót implementálnak, és támogatja a kezelők ( angol hooks ) elindítását is, vagyis olyan szkripteket, amelyek egy esemény bekövetkeztekor indulnak el. Az Fs és Repos szintek együttesen alkotják a fájlrendszer interfészt . mod_dav_svn WebDAV / Delta-V hozzáférést biztosít az Apache 2 - n keresztül. Ra Tárolási hozzáférést valósít meg (helyi és távoli is). Ettől a szinttől kezdve a tárhelyre URL-en keresztül lehet hivatkozni, pl.A Subversion szabványos ügyfélsegédprogramját, az SVN-t környezeti változók és a felhasználó saját könyvtárában egy alkönyvtárban létrehozott INI-fájlok.subversion konfigurálják (a konfiguráció helye a Windows rendszereken, a fájlokban vagy a rendszerleíró adatbázisban a rendszerbeállításoktól függ). A konfigurációban az SVN az SSL-tanúsítványokat, bejelentkezési adatokat, jelszavakat stb. is gyorsítótárazza (hacsak nincs letiltva a konfigurációban) a Subversion szerverek eléréséhez.
A könyvtár tartalma .subversion:
Előfordulhat, hogy a Subversion nem mindig kezeli megfelelően a fájl átnevezéseket, ha a fájl tartalma az átnevezéssel egyidejűleg megváltozik. Problémák adódhatnak akkor is, ha a helyi másolatban átnevezett fájlt valaki más módosítja a tárolóban. A problémák némelyikét az 1.5-ös verzió javította, de ez a megoldás még nem készült el. [53]
A fiókegyesítési műveleteket is a Subversion gyenge pontjának tekintik. Az 1.5-ös verzió előtt a felhasználóknak minden ilyen műveletet manuálisan kellett nyomon követniük részletes változásnapló-bejegyzések segítségével. Az 1.5-ös verzió óta bevezették az automatikus egyesítés-követés alapszintű támogatását, amelyet a fejlesztők a későbbi kiadásokban továbbfejlesztenek [54] . A Subversion jelenleg elég jól támogatja a gyakori összevonási forgatókönyveket; bonyolultabb esetekben problémák adódhatnak. Javasoljuk [55] , hogy a munkafolyamatot úgy szervezzék meg, hogy elkerüljék a problémás forgatókönyveket. Az átnevezett fájlok és könyvtárak egyesítése nem támogatott.
A Subversion lerakatba helyezett információk örökre ott maradnak: egy fájl törölhető az aktuális változatnál, de mindig vissza lehet állítani a lerakatból a korábbi változatok valamelyikét, amelyben a fájl létezett. Bár a korábbi verziók megőrzése valójában a verziókezelő rendszerek használatának célja, néha teljesen el kell távolítani a tévesen odahelyezett információkat. A Subversion erre semmilyen natív módot nem ad [56] ; az egyetlen lehetőség egy tárolási kiírat létrehozása, feldolgozása a szabványos svndumpfilter segédprogrammal, majd a tároló visszaállítása a kiíratból. Vannak harmadik féltől származó programok is, amelyek automatizálják ezt a folyamatot, de mindenesetre ehhez a művelethez a tárolóhoz való hozzáférés ideiglenes felfüggesztésére és egy olyan rendszergazda beavatkozására van szükség, aki elég magas jogosultságokkal rendelkezik ahhoz, hogy teljesen törölje a régi tárolót, és cserélje ki egy újjal. egy.
|
Név |
Leírás |
Nyelv |
DB |
Engedély |
Weboldal |
Frissítés |
Változat |
|
Wiki technológián alapuló eszköz |
Piton |
SQLite, PostgreSQL, MySQL és MariaDB |
trac.edgewall.org Archiválva : 2013. április 8. a Wayback Machine -nél |
2017.06.21 |
1.2.2 | ||
|
további hibakövetés |
rubin |
MySQL, PostgreSQL, SQLite, Oracle. |
redmine.org Archiválva : 2011. április 27. a Wayback Machine -nél |
2018.12.09 |
4.0.0 | ||
|
SVN-re specializálódott segédprogram a lerakatokhoz való hozzáférés létrehozásához és kezeléséhez |
PHP |
MySQL, SQLite |
CeCill (GPL-kompatibilis licenc). |
www.usvn.info Archiválva : 2011. május 12. a Wayback Machine -nél |
2012.01.13 |
1.0.6 | |
|
ViewVC |
felhasználókezelés nélkül, nem igényel DAV támogatást a webszervertől. |
Piton |
MySQL |
Kéttagú Berkeley-stílusban |
www.viewvc.org Archiválva : 2011. május 4. a Wayback Machine -nél |
2010.12.02 |
1.1.8 |
|
WebSVN |
böngészési felület az SVN-hez |
PHP |
XML |
websvn.tigris.org Archivált : 2006. június 12. a Wayback Machine -nél |
2010.10.12 |
2.3.2 | |
|
segédprogram adattárak kezeléséhez (létrehozás, törlés, be- és kirakodás; felhasználók és csoportok kezelése) |
PHP |
MySQL vagy SQLite |
svnmanager.sourceforge.net Archiválva : 2011. április 30. a Wayback Machine -nél |
2012.01.28 |
1.09 | ||
|
Beküldés (MIT) |
segédprogram adattárak és felhasználók kezeléséhez, beleértve a lerakatban lévő egyes könyvtárak hozzáférés-vezérlésének kezelését |
Piton |
MIT/X archiválva : 2011. június 6. a Wayback Machine -nél |
2012.12.24 |
2.1 | ||
|
cSvn |
webes felület a Subversion adattárak megtekintéséhez |
C |
csvn.radix.pro Archiválva : 2022. március 16. a Wayback Machine -nél |
2020.11.17 |
0.1.3 |
| Verzióvezérlő rendszerek ( kategória ) | |
|---|---|
| Csak helyi | |
| Kliens-szerver | |
| Megosztott | |
| URI- sémák | |
|---|---|
| Hivatalos | |
| nem hivatalos | |