On 2012/11/20 4:54 AM, Nico Kadel-Garcia wrote:
> On Mon, Nov 19, 2012 at 9:11 AM, Gunther Mayer
> <gunther.mayer_at_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).
Received on 2012-11-24 12:12:11 CET