Hello Josh,
Thanks a lot for your answer.
The fsfsverify script indeed managed to fix the problem:
I recovered the repository without a tedious and risky dump/load.
And I'll have a serious look at 1.4.2...
Thanks again,
Samuel
> ----- John Szakmeister <john@szakmeister.net> wrote:
> > ----- Samuel Langlois <slanglois@ilog.fr> wrote:
> > [snip]
> > > We are using svn 1.3.2 on Linux, exclusively through the http://
> > > protocol
> > > (Apache/2.2.2 (Unix) mod_ssl/2.2.2 OpenSSL/0.9.7a DAV/2 SVN/1.3.2)
> > > The repository format is fsfs.
> > > The whole repository is rather big (several GB, 66,000 revisions);
> > > it is coming from a CVS import through cvs2svn.
> > > It is the first time we encounter such a problem in six months of
> > > work.
> > >
> > > Is there anything that I can look at to help diagnose the problem
> > > further?
> > > Is this a known issue?
> > > How can I be sure that this does not happen again?
> > > Thanks for your help
> >
> > It is a known issue, and I believe it has been fixed in the latest
> > version (1.4.2).
>
> FWIW, the issue that was fixed isn't related to bucket brigades. There was another issue where a
> handle to the revision would remain open, and would get closed when the pool was destroyed. The last
> block of data would be written out and corrupt the revision.
>
> >
> > As for fixing the problem, have a look at fsfsverify. A number of
> > people have been able to successfully recover their repositories with
> > it.
>
> I meant to provide the link:
> http://www.szakmeister.net/fsfsverify/
>
> -John
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jan 3 11:44:44 2007