SVN-Repository reparieren?

Gast #732569
Hallo Allerseits,

für alle meine Projekte habe ich ein subversion-Repository auf einem 
kleinen Server eingerichtet. Neulich bekam ich beim frischen Auschecken 
eines Projektes eine seltsame Fehlermeldung, dass eine Datei nicht 
gefunden werden konnte.

'svnadmin verify <PROJEKT>' gab mir den Hinweis, dass eine 
Revisionsdatei keine Leerzeile am Dateiende besitzt. Als ich diese Datei 
(Revision 16 von 30 Revisionen, also mittendrin :( ) geöffnet habe, fiel 
mir auf, dass sich deren Inhalt von dem der anderen Revisionsdateien 
unterscheidet - hier war nur unleserlicher Binärkram enthalten. Von 
daher gehe ich aus, dass diese Datei defekt ist.

Gibt es einen Weg, dieses zu reparieren?
Gast #732570
Nachtrag:
ich habe noch eine komplette Arbeitskopie dieses Repositories auf einem 
anderen Rechner - könnte ich evtl. daraus die korrupte Revisionsdatei 
neu generieren?
#732594
>hier war nur unleserlicher Binärkram enthalten. Von
>daher gehe ich aus, dass diese Datei defekt ist.
Die anderen waren lesbar? Ich dachte, SVN komprimiert...
Wenn deine aufgezeichnete Änderung eine Binärdatei betroffen hat, so 
wird der Inhalt der Rivisionsdatei wohl auch binär sein.

- Kannst du eine alte Revision auschecken?
- Hast du mal nach der exakten Fehlermeldung im Web gesucht?
- Bietet svn admin keine repair-Funktionen an?

Ich habe selbst mit SVN noch nicht so viel gemacht...

Gruß

Kai
Gast #732607
Du hast Recht: in allen Revisionsdateien sind unleserliche Stellen 
enthalten, nur zum Dateiende hin sind sind die Einträge wieder lesbar - 
in der korrupten Datei jedoch nicht.

- Ich kann alle Teilprojekte bis Revision 15 auschecken, ein Projekt 
lässt sich sogar bis Revision 30 updaten.
- Ja, ich habe aber noch nichts Brauchbares gesehen
- Ich habe keine gefunden
#732623
Die Doku ist da ziemlich eindeutig:
"that means that your repository has at least one corrupted revision and 
you should restore the corrupted revision from a backup (you did make a 
backup, didn't you?)."

Auch wenn dir das nicht gefallen wird.

Mach erstmal ein Backup von deinem defekten Repository () und versuch 
dann mal alle Revisionen ab und inklusive der defekten zu löschen. Und 
check dann deine working copy ein. Wenn das klappt (verify) hast du nur 
ein paar Revisionen verloren. Ist aber nicht vorgesehen und ich habe 
keine Ahnung, ob das für Langzeitschäden sorgt! Du wirst dem evtl 
irgendwie nach dem Löschen noch mitteilen, dass die aktuelle Revision 
eine andere ist.

Zur Not: alles löschen und neu einchecken.

Backup beschrieben in:
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.reposadmin.maint.backup
#733380
Nachdem mir nun bewusst ist, dass ich eine Backup-Lösung für meine 
Repositories brauche, stellt sich die Frage, wie man dieses effektiv 
angeht?

Aus meiner Sicht müsste das Archiv über eine Historie verfügen, damit 
sich auch Probleme, die in der Vergangenheit liegen, beheben lassen. 
Andererseits möchte ich ungern jedesmal einen 'full dump' machen.

Da ich mich mit meinen Basteleien ausschliesslich im Hobby-Bereich 
bewege, brauche ich keine Multi-k€ Backuplösung mit X redundanten 
Servern.

Wie wird das von Euch gehandhabt? Einige Leute verwenden rsync, andere 
inkrementelle tar-Archive...

Wie sind so die Erfahrungen mit rsync / tar?
#733766
Externe Platte am Linux-Server und folgende Scripts:

Datei: backup-daily
1
./backup /mount/backup/daily/`date +%u-%A`

Datei: backup-monthly
1
./backup /mount/backup/monthly/`date +%m-%B`

Datei: backup
1
rm -rf /tmp/backup
2

3
mkdirhier /tmp/backup/svn-myproject
4
cd /tmp/backup/svn-myproject
5
svnadmin hotcopy /var/svn/myproject .
6
tar -czf $1/svn-myproject.tar.gz *
7

8
rm -rf /tmp/backup

backup-daily wird täglich aufgerufen und backup-monthly monatlich (soll 
es zumindest mal, wenn ich die Berechtigungen hingekriegt habe - im 
Moment starte ich die manuell).

Die Platte muss insgesamt 7+12 = 19 Vollbackups fassen. tar kann aber 
auch inkrementell arbeiten, das ist wahrscheinlich das, was du suchst.

Restore testen nicht vergessen.

Keine Garantie für gar nichts - bin selber noch am lernen ;)
Gast #736954
Benutze kein SVN, sondern GIT, aber:

Die mit GnuPG verschlüsselten Repository-Backups brenne ich auf CD. 
Source-Code ist zu wertvoll.

Der GnuPG-Archiv-Key ist übrigens an verschiedene Stellen hinterlegt 
(verschiedene Ortschaften!).

Der Vorteil der gebrannten CDs ist mehrfach:

  - Kann nicht ausversehen gelöscht werden.
  - Kann nicht durch Überspannung zerstört werden.
  - CDs können auch in Bankschließfächern verwahrt werden.

D.h. die Hütte kann sogar abbrennen, und ich kann meine (u.a.) 
Source-Codes wieder restaurieren.

Das beruhigt die Nerven ungemein. So ein Bankschließfach kostet auch 
nicht die Welt, und die CD-Rohlinge erst recht nicht.

Antwort schreiben

Eine eigene Frage? Dieser Thread ist über 18 Jahre alt. Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.

Neuen Thread starten

Eine Lösung, Ergänzung oder Rückmeldung zu diesem Thread? Dann antworte hier.

Formatierung
  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] – Link zu einem Artikel
  • Verweis auf einen anderen Beitrag: Rechtsklick auf dessen Beitrags-ID (#8078628), „Adresse kopieren“, in den Text einfügen

Mehr zur Formatierung

Längeren Sourcecode als Anhang, nicht in den Text. JPG nur für Fotos und Scans; Zeichnungen und Screenshots als PNG oder GIF. Siehe Bildformate.

Schon registriert? Anmelden

Wird nicht angezeigt. Wir schicken dir einen Link; sobald du damit bestätigst, erscheint dein Beitrag.

Mit dem Abschicken legst du einen kostenlosen Account an und erkennst die Nutzungsbedingungen und die Datenschutzerklärung an.