On 2012/11/20 4:54 AM, Nico Kadel-Garcia wrote:
On Mon, Nov 19, 2012 at 9:11 AM, Gunther Mayer
<gunther.ma...@googlemail.com> wrote:
Hi there,
I'm the sysadmin for our small company (8 employees) and we're running all
our shared files over a subversion server. Some time ago our server had
faulty memory which resulted in corrupt entries being written to the
underlying fsfs db, later propagating to backups too. This resulted in four
corrupt revisions in my /var/svn/myrepo/db/revs/XXXX, one of which I managed
to fix manually with fsfsverify and a whole lot of hacking/fudging. The
other three however are beyond me and I can't afford to spend days of trying
to figure out how to fix it (and fsfsverify can't do it either, it keeps
choking on the same issue). The problem is that I cannot take a full backup
of my repository or create a new working copy from scratch as any command
(e.g. svnadmin verify, svn co etc.) that comes across these revisions chokes
and dies, always with the dreaded "Decompression of svndiff data failed"
error.
Which version of Subversion are you running with? Do you have the
latest revisions, to use the latest repair tools? And can you do an
export of the current contents, set aside the old repository, and
switch people to the new repo with the necessary tags, but without the
corrupted history? This is an approach I've used successfully for
people migrating among source control systems or cleaning up projects
where inappropriae data was in the primary repository. (Spurious DVD
images and files with passwords were particularly common problems.)
I'm still using svn version 1.6.18 (r1303927), haven't bothered yet to
upgrade to 1.7 because I haven't seen the need. Correct me if I'm wrong
but I thought a corrupted revision will choke svn 1.7 just as much as
1.6 as the underlying fsfs structure hasn't changed across versions. I
did ensure, however, that I'm using the latest version of fsfsverify.
You're right, I can export all current contents and create a new
repository from it but then I lose all the history which is exactly what
I don't want. I might end up using a hybrid approach though - fixing the
smaller two corrupt revisions and starting from scratch for the big one
(1.5GB) as it's very early in my history (r6).
