Problem mit SVN: BDB inkonsistent

[Murray]

Hallo,

beim Versuch, das SVN auf einen neuen Server zu mirgrieren, hat sich herausgestellt, dass die Datenbank offenbar seit ein paar Tagen korrupt ist.

Eigentlich sollte das Repository per svndump exportiert und anschliessend auf einem anderen Rechner in eine neue Version (dann nicht mehr mit BDB, sondern FSFS) eingespielt werden; leider gibt es beim Dumpen folgende Fehlermeldung:

svn: Berkeley DB error while opening 'changes' table for filesystem /mnt/sdd1/svnroot/db:
Das Argument ist ung?\252ltig
svn: bdb: /mnt/sdd1/svnroot/db/changes: DB_DUP specified to open method but not set in database

Mit den Backups der letzen Tage passiert leider das gleiche; wir müssten also ziemlich weit zurückgehen, wobei sich dann die Frage stellt, was mit den Clients passieren muss, die ja bereits Revisions haben, die in diesem alten Backup noch nicht enthalten sind.

Hat jemand schon mal mit so einem Problem zu tun gehabt?

 

[kama]

Hi,

BTW: Welche Subversion Release? BDB Release? etc.?

zuerst einmal ein "svnadmin verify" machen?

Backups Prüfen auch ältere....und bis zu dem Punkt zurück gehen, der wieder funktioniert...

"svnadmin recover"....und beten....

Wenn der aktuelle Stand auf einem Client vorhanden ist, kann u.U. überlegen die Versionen die man noch bekommt zu migrieren und dann den letzten Stand von einem Client aus wieder einchecken. Es geht selbstverständlich dann etwas verloren...

EDIT: Wie hab't ihr denn einchecken können?

MfG
Karl Heinz Marbaise

 

[Murray]

BTW: Welche Subversion Release? BDB Release? etc.?

Ist noch immer die gleiche Konfiguration wie hier:
svn, Version 1.1.4 (r13838)
übersetzt May 13 2005, 06:29:47

EDIT: Wie hab't ihr denn einchecken können?

Das Problem ist erst beim Dump aufgetreten, als wir auf die neue Version migrieren wollten. Das Einchecken schien bis dahin funktioniert zu haben; sollten dabei irgendwelche DB-Fehler aufgetreten sein, so sind diese zumindest nicht bis an die (Eclipse-)Oberfläche durchgedrungen.

Möglicherweise sind ja auch nicht alle Module betroffen, so dass man arbeiten konnte, solange man nicht das inkonsistente Modul am Wickel hat.

svnadmin recover und auch die direkte Recovery der Berkley-DB haben keine Besserung gebracht.

 

[Murray]

So, jetzt hat die Migration doch noch geklappt: möglicherweise war das Filesystem der alten Maschine etwas angeknackst. Nachdem das Backup auf einen anderen Rechner kopiert wurde, konnte man es dumpen und den Dump in die neue Version importieren.