inkrementális/differenciális mentések

Segédprogramok

Az arj windowsos verziója (ARJ32 v. 3.10 ARJ Software Russia) képes egyfajta inkrementális archívum létrehozásár - "chapter" -kel és és csak azt menti (a már meglévő halmazba) ami új/módosult. Kibontáskor meg lehet adni melyik állapotnak megfelelőt bontsa ki (melyik "chapter").
A Derbian-ban fellelhető arj ilyet nem tud :( Tud valaki hasonló tulajdonságú, Linux (Debian leginkább) programot?

Egyébként, sok évnyi, alapvetően C programok kezeléséről van szó. Gondolkodtam a verzió követésben is. Húzódozom a cvs és fejlettebb társaitól. Nem egy masszív projektről van szó, hanem sok kisebb/nagyobb dologról, program csomagokról és rövid egy-két állományos "piszkozatról". Valami egyszerű átlátható megoldásra lenne szükségem, amihez nem kell nagyon komoly infrastruktúra a háttérben, ahhoz hogy egy-egy dolog, konkrét verziójához hozzáférjek. Kezd a probléma túlnőni a fejemen, nem tudom tovább így kezelni. Minden javaslatot szívesen vennék. Az aktuálisan karbantartott anyag ck. 200 megabájtnyi kód főleg szöveg alapú állomány.
Még egy adalék, hogy a windows -ra írott programjaim annyiban térnek el a Linux -ra írottaktól, hogy sokkal több a bináris állomány. Még a multi chapter arj -vel kézben tudom tartani, de ez is határeset Ráadásul a több éves serény munka több gigabájtnyi állományt termett.

  • 2498 megtekintés

( szemet | 2010. 10. 08., p – 12:44 )

Az RFC 3284 jó lehet neked...

És azt megvalósító implementációval próbálkozhatsz. Esetleg, pl.: http://xdelta.org/

szerk: egyébként legegyszerűbb megoldás: a verziókat együtt betömöríted olyan progival aminek van "solid archiving" funkciója (pl. rar), vagy tar-olod olyan sorrendben, hogy egy konkrét fájlból az egyes verziók egymáshoz közel legyenek -> ekkor bármilyen tömörítő kiszedi a felesleges redundancia zömét...

pont az lenne az inkrementálisnak az előnye hogy ne kelljen minden egyes új fájl mentésénél a többit beolvasni, kitömöríteni, hozzáadni, betömöríteni, kiírni
100 byte hozzáírás helyett mondjuk gigabájtot ki-be tömörítgetsz, irkálsz :)

hogy subscribe helyett mondjak is valamit:
rsync, vagy inkább meg kell ismerni egy verziókezelőt és akkor már átlátható lesz:)
(ha ezeket egy tömörített fájlrendszere teszed, akkor már a kényelmet is beleszámítva nem vesztes olyan nagyon sok helyet)

( csardij v | 2010. 10. 08., p – 12:54 )

de mia baj az svn-nel? Nem muszáj mindenféle szerver hozzá, fájlrendszeren is használhatod.

Nem ismerem eléggé az svn -t :( És most éppen nincs túl sok olvasgató időm.
> Nem muszáj mindenféle szerver hozzá, fájlrendszeren is használhatod.
Ezt úgy értsem, hogy ha lementem/eltárolom az aktuális svn könyvtárat akkor azt egy bármilyen gépen elővehetem és a tetején, fájl szinten az aktuális, utolsó állapotot kapom? - ez szép, de ha elő kellene rántanom egy-két módosítással előbbi állapotot akkor ezt hogy tudom szerver nélkül megtennem?

* Én egy indián vagyok. Minden indián hazudik.

Ezt ugy erti, hogy a repository (verzios adatbazis) lokalisan egy konyvtarban is lehet. Ergo nem kell hozza svn szervert beuzemelni.
A fajljaidat ugy kapod vissza, hogy checkout -olsz a repositiry -bol. Igy lesz egy working copy -d, ami a fajlokat tratalmazza. Ha regebbi verzio kell, lehet tetszoleges regi allapotot checkout -olni, vagy mar meglevo working copy -t update -olni regi verziora.
Hatranya, hogy minden a working copy -ban levo konyvtarba tesz egy .svn konyvtarat ahol a kliens nyilvantartja a working copy allapotat. Azaz pl ha a /etc -t betolod svn -be, az osszes konyvtarban keletkezik egy .svn konyvtar nehany fajllal. Ez nem okoz bajt, csak nem szep.

bzr vagy gitet javasolnam neked. osszetarolod a konyvtarat, .bzr-estul (vagy .git-estul), es voila, ott a teljes history is vele. regebbi valtozatot is trivialisan elokapsz vele, nem kell hozza szerver sem.

jobban jarsz egy verziokezelovel, mintha sajat magad akarnal feltalalni valami hasonlot. gyorsabban mukodesre birod, es valoszinuleg megbizhatobb is lesz.

Hát, ha én meg tudtam tanulni, akkor neked is menni fog :D És nem is kellett hozzá sok idő.

Ami nagy trükk (ehe) volt, hogy az svn "szerver" úgy legyen konfigurálva, hogy az újabb svn repository-k hozzáadása egyszerű legyen. Most már csak egy svnadmin create parancs, és már mehet is a buli. De természetesen nem kell hozzá szerver se, tud lokális könyvtárból is működni.

( tovis v | 2010. 10. 08., p – 15:15 )

Azt hiszem tudom már miért húzódozom svn és társaitól - nem látom őket át, nem tudom mi van ha valami "bedöglik".
(Talán az is hozzájárul, hogy van egy olyan alkalmazási komplexum amit utoljára - az ottani fejlesztők tanácsára - svn -nel húztam le és nem működik)
Egyébként, hogy néz ki az svn szerver? El lehet igazodni az általa karbantartott cuccokon?

* Én egy indián vagyok. Minden indián hazudik.

Ilyen alapon, mi van, ha az arj bedoglik (mondjuk megserul a file valami nagyon kellemetlen helyen)?

Egyebkent svn-en egyszeruen el lehet igazodni. De, ha olyan megoldast keresel, amihez nem kell szerverrel vacakolni (meg annyit se, hogy beallitani, hogy ne legyen ilyen), akkor a "distributed" VCS-ek egyiket lenne erdemes kiprobalnod szerintem.

En gitet javasolnam, mert alapjaratban kegyetlenul egyszeru. Amig annyit hasznalsz belole hogy uj verzio becommit, meg neha regi vissza, meg hurcibalod a dirt ide-oda kulonbozo gepekre, addig alig 3-4 parancsot kell ismerni (init, checkout, log, commit; kb :P).