Hallo zusammen, "kein Backup - kein Mitleid" - Womit ich mir jetzt Arbeit aufgehalst habe, habe ich selbst zu verantworten. Mir ist ein Datenträger, auf dem sich ein SVN-Repository befindet, kaputtgegangen. Insgesamt gibt es aber von den Dateien des letzten Versionsstandes ein Backup, und da es sich um ein Privatprojekt handelt, ist es ein reines Luxusproblem, dieses Repository wiederherzustellen. Nichtsdestotrotz will ich es versuchen. Immerhin war das Dateisystem noch gut genug, daß sich eine Kopie des Repository-Verzeichnisses erstellen ließ, aus der sich die aktuelle Revision (279) auschecken lies. Ein Dump dieses Repositories funktioniert allerdings nicht mehr (Fehler: "No such revision 99"). svnadmin verify ist sogar der Meinung, daß die Revision 98 nicht existiert. svnadmin recover melded sich mit "completed" ohne Fehler. Der letzte Full dump ist von Revision 209. Die meisten Revisionen zwischen 209 und 279 lassen sich verifizieren. Daher die Frage in die Runde: Kann ich aus einem teilbeschädigten Repository und einem intakten Dump den Versionsverlauf wiederherstellen und wie? Viele Grüße W.T.
Walter T. schrieb: > Die meisten Revisionen zwischen 209 und 279 lassen sich verifizieren Wenn sich zwischendurch viel geändert hat? Eine Hose, die zu viele Löcher hat, schmeißt man weg. Parallel zum kompletten Backup mache ich gern eine Liste aller Dateien. Die kann man später vergleichen und erkennt Differenzen.
oszi40 schrieb: > Eine Hose, die zu viele > Löcher hat, schmeißt man weg. Generell hast Du Recht, aber: 1. In den Versionsständen zwischen 209 und 279 sind nur wenige Löcher an Stellen, wo es vertmutlich nicht weiter stört und 2. Betrachte ich dies als Gelegenheit, den Ernstfall für ein defektes Repository zu proben, das wirklich wichtig ist.
Ein Entwurfsziel bei Subversion bestand darin, dass bei Commits im Repository keine bestehenden Dateien verändert oder gelöscht werden dürfen, sondern ausschließlich neue Dateien hinzukommen. Die einzige Ausnahme ist der Revisionszähler db/current, in dem die letzte Revision im Klartext steht. Nur beim nachträglichen Änderung von Revision Properties, z.B. einem Checkin-Kommentar werden bestehende Dateien verändert, wobei dies aber sehr seltene Vorgänge sind. Ansonsten gibt es nur die sog. Transactions, d.h. eine Ansammlung von Dateien, die während der Übertragung der Daten vom SVN-Client an den Server angelegt und nach erfolgreichem Commit wieder gelöscht werden. Falls aus irgendeinem Grund die Übertragung abgebrochen wird, können die Relikte der Transaction im Repository bestehen bleiben, haben dort aber keine Funktion mehr. Sie lassen sich einfach per "svnadmin lstxns" bzw. "rmtxns" wieder entfernen. Oder auch durch händisches Löschen der entsprechenden Dateien aus db/transactions und db/txn-protorevs. Bei der inneren Struktur der SVN-Repositories hat es aber auch mehrere Änderungen gegeben. Hierbei war die Einführung der Merge-Tracking-Datenbank in SVN 1.5 so ziemlich die wichtigste. Diese liegt nicht als Klartextdatei vor, sondern als SQLite-Datenbank und kann mit Hilfe des Programms sqlite3 auch inspiziert werden. Um zu überprüfen, ob diese Datenbank beschädigt wurde, kann Du das Kommando 'sqlite3 db/rep-cache.db "pragma integrity_check"' verwenden. Ansonsten spricht überhaupt nichts dagegen, die fehlenden/beschädigten Dateien in den Verzeichnissen revprops und revs mit Hilfe Deines alten Backups zu rekonstruieren bzw. blind zu überschreiben. Da Subversion alle Revisionen als Diffs gegenüber bestehenden Revisionen speichert, müssen natürlich sämtliche alten Revisionen vollständig verfügbar sein. Abschließend solltest Du unbedingt "svnadmin verify <repository>" ausführen. > 1. In den Versionsständen zwischen 209 und 279 sind nur wenige Löcher > an Stellen, wo es vertmutlich nicht weiter stört und Das ist eine Fehlannahme. Es mag zwar sicherlich Revisionen geben, von denen niemals andere Revisionen abgeleitet wurden, aber dies sollte man nicht verallgemeinern. Früher oder später würde ein lückenhaftes Repository zu Inkonsistenzen führen. Natürlich gibt es auch hier den obligatorischen Hinweis, dass Du all diese Operationen natürlich nur auf einer Kopie des echten Repositories durchführen solltest.
:
Bearbeitet durch User
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.