SVN-Repository reparieren?

Gast Gast #732569
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
Kai G. #732594
Lesenswert?
• ▲
▼ 
>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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Gast Gast #732607
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Kai G. #732623
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Oliver S. #733380
Lesenswert?
• ▲
▼ 
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?
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Kai G. #733766
Lesenswert?
• ▲
▼ 
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 ;)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Unbekannter Gast #736954
Lesenswert?
• ▲
▼ 
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 Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren