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.)
Received on 2012-11-20 03:55:05 CET