Hi zusammen,

ich habe folgendes Problem.
Ich habe ein QNAP TS109 NAS. Auf diesem habe ich einen SVN-Server 
laufen, damit ich meine diversen LaTeX-Files und Sourcecode von 
verschiedenen Projekten aufbewahren kann. Soweit so gut. Das Ding läuft 
im Grossen und Ganzen. Nur stelle ich fest: immer nach einer gewissen 
Betriebsdauer kriege ich beim ein- oder auschecken eines Files im SVN 
die Fehlermeldung "Couldn't perform atomic initialization / Database 
disk image is malformed".
Durch ausgiebiges Gurgeln habe ich herausgefunden, dass sich dieser 
Fehler nicht beheben und das Repository verloren ist.
So. Dieser Fehler ist vor einem Jahr schonmal aufgetreten. Damals hatte 
die Harddisk im NAS bereits ein paar "Reallocated Sectors", sodass ich 
das Problem mal diesen zugeschoben habe. Dann habe ich halt einfach ein 
neues Repository angelegt und weiter gearbeitet.
Nun habe ich aber seit 2 Monaten eine neue Platte im NAS. Diese ist 
garantiert fehlerfrei. Gestern Abend habe ich mal wieder ein File 
eingecheckt, das ging problemlos. 10sec später wollte ich noch was 
anderes einchecken. Und? Nun kommt wieder diese Fehlermeldung! Was soll 
das?
Kennt jemand von euch dieses Problem mit SVN, weiss einer, woran es 
liegen könnte? ich habe nur wenig Lust, dauernd ein neues Repository 
anzulegen :-(
Gibts vllt. eine Lösung, um das "malformed database disk image" 
wiederzubeleben?

Auf welche Weise greifst du auf das SVN zu nd welchen Databasetyp nutzt 
du? Einige sind für Networkshares nicht geeignet (steht auch in der 
Doku!) und sollten nur z.B. über Apache+Webdav oder svnsrv genutzt 
werden.

Hi Läubi,

ja, ich weiss dass man auf das SVN nicht über ein Share zugreifen 
sollte.
Mein NAS läuft mit einem Linux, und direkt auf diesem Linux läuft auch 
der SVN-Server. Er lauscht auf Port 3690, sodass ich mit dem svn:// 
Protokoll drauf zugreifen kann. Ich benutze also KEIN share, der Ordner, 
wo die Repos drin liegen ist gar nicht freigegeben!

Das ist dann natürlich merkwürdig kannst du den lokal mit den svn tools 
noch zugreifen? Beizeiten ein Backup des Repros gemacht?
Eventuell ist aber auch die SVN Version selbst buggy? Ich benutze 1.6.12 
(r955767) recht intensiv (allerdings hauptsächlich lokal) und hatte 
bisher keine Probleme.

Lokal habe ich noch nie versucht, auf das Repository zuzugreifen. Da 
benutze ich einfach nur svnadmin (via SSH) um ein Repository zu 
erstellen, und in der autorun.sh steht einfach noch ein Befehl drin, der 
den SVN Daemon (oder wie das heisst) startet. Sonst habe ich lokal noch 
nie zuzugreifen versucht. Ich habe da nur eine Konsole zur Verfügung; 
was kann ich damit zugreifen?

Mein svnadmin sagt folgendes:

[~] # svnadmin --version
svnadmin, version 1.6.17 (r1128011)
   compiled May  4 2012, 02:44:56

Copyright (C) 2000-2009 CollabNet.
Subversion is open source software, see http://subversion.apache.org/
This product includes software developed by CollabNet (http://www.Collab.Net/).

The following repository back-end (FS) modules are available:

* fs_fs : Module for working with a plain file (FSFS) repository.

sagt dir das was?

Tobias Plüss schrieb:
> Ich habe da nur eine Konsole zur Verfügung;
> was kann ich damit zugreifen?

z.B. so:

cd /tmp/
svn co svn://mein/repro/ ...

Ansonsten mal die Smartwerte der HD anschauen, eventuell wird dein NAS 
zu warm?

Hi Läubi,

sorry für die späte Antwort.

Also, auschecken geht noch immer, sowohl auf meinem PC mit TortoiseSVN, 
als auch auf dem NAS in der Konsole mit deinem Befehl. Die Meldung, dass 
die Database kaputt sei, kommt nur beim einchecken... :o