Subversion mentés

Svn gyökérkönyvtár alatt ugye arra gondolsz, ahol a conf, dav, db, hooks, locks könyvtárak és a README.txt és format fájlok állnak? Igen, egy svn commit meg ilyesmi csak ide dolgozik, tehát ez a teljes repó. Persze nyilván apache konfigot meg ilyesmit is menteni kell, de az nem változik a rendes használat során, csak karbantartáskor. Hasonlóan mondjuk a repó fájlrendszer jogosultságait meg ilyesmit is illik menteni.

A fenti mellett ugyanakkor javaslok még egy fajta backupot. Ugyanis elvileg az adatbázis megsérülhet. Régesrégen volt, hogy így jártunk, amikor a berkeley db nevű okádékot használta még a subversion. Manapság a saját "fsfs" nevű implementációjukat használja alapból (lásd db/fs-type), ezzel még nem volt ilyen bajunk, de jobb félni, mint megijedni. Mi nagyjából az alábbit csináljuk:
svnlook youngest /path/to/repo ==> megmondja a revision értéket
svnadmin dump /path/to/repo -r1234 --incremental ==> csinál egy tök normális olvasható formátumú dumpot az 1233-1234 közti változásról, ezt eltároljuk egy fájlban, és mindig lefuttatjuk az összes olyan új commitra, amire még nem létezik ilyen fájl. Ennek a fájlnak a szintaxisa független az svn által használt adatbázistól, és szükség esetén az "svnadmin load" paranccsal bármikor újrajátszható egy ilyen commit, ezáltal az ilyen dump fájlokból akár nulláról is újra felépíthető a repó. Egyébként a replikációt is így oldjuk meg, a fő svn dumpol ily módon rendszeresen, a dump fájlok rsync-kel szinkronizálódnak, a túloldal pedig az újonnan megjelent fájlokat svn load-dal betolja az ottani (read-only) repóba.

Ennek a backup megoldásnak hátránya, hogy a konfigurációs adatokat (például commit hooks) nem archiválja, csak a tényleges commitokat. Előnye viszont, hogy normális, emészhető formátumú, független a subversion és a rendszeren lévő egyéb libek verziójától meg ilyesmiktől, szóval ha minden nagyon-nagyon összedől, akkor IMHO jóval használhatóbb, mint a repó low-level mentése. Szóval ha rám hallgatsz, mindkét módszer együtt a nyerő :)