While I don't think corruption best describes it, the repo is definitely
broken, and seemingly from an aborted commit...
I've compiled a svn server from the 0.24.2 tarball on Debian GNU/Linux.
I've created a repo and configured the paths and user authentication and
access was going fine. There are three users, all using the windows
client (0.24.2) as found on the subversion site.
To get all our work in we started with 3 directories, one for each of
user. I was the first person to add my work, and had no issues; call me
'A'. The next person, 'B', added their work, but aborted the commit
before ~30MB could be committed. The third person, 'C', added their
work just fine. Person B performed their commits again, this time
without aborting, all seeming to go fine. When A and B tried to status
the update (svn status -u) the client took a while, then eventually
crashed with a 'Dr. Watson' type of log being generated. I checked via
web browser and through that interface I was able to view the commits
from 'B', in the original directory and file structure with no apparent
problems. I checked the error logs and there were none listed in the
Apache error log. I checked the condition of the repo with svnadmin
lstxns and had 4 failed transactions. Since Bs committed files were
appearing in the browser view I thought I'd removed those transactions
(after making a backup of the broken repo). No error messages, so I did
another update, again same issue: client took a while, then produced a
'Dr. Watson' error. Looking at the Apache error log I saw an error
message stating that I should run svnadmin recover on the database:
[Fri Jul 04 23:29:03 2003] [error] [client 192.168.0.3] Could not fetch
resource information. [500, #0]
[Fri Jul 04 23:29:03 2003] [error] [client 192.168.0.3] Could not open
the SVN filesystem at /var/lib/svn/repositories/testRepo [500, #160029]
[Fri Jul 04 23:29:03 2003] [error] [client 192.168.0.3] (17)File exists:
Berkeley DB error while opening environment for filesystem
/var/lib/svn/repositories/testRepo/db:
DB_RUNRECOVERY: Fatal error, run database recovery [500, #160029]
After doing so, and starting apache back up I still had the same
problems, the client crashed, but the web view worked fine. And this
time svnadmin lstxns was not aware of any failed transactions. Since we
all had our work on our local drives I moved the repo out of the way and
created a new one to test against. Fortunately, or unfortunately we
were able to reproduce this on another repo, following the same steps:
add a bunch of directories and files; commit; abort the commit.
For kicks I tried using the client that got compiled on the server, and
it produced a seg fault at the same place the windows clients did.
Is this something we should be expecting to happen with the pre beta
builds? Could I have misconfigured the repo? Is that the proper way to
try and recover a repo?
I still have the broken repo around, and if we can get past some
confidentiality issues we could probably hand it off for examination if
need be,
When replying, please reply to this email as well since I'm not
currently subscribed to the list, although I am checking the web archive
regularly.
Thanks for you time, and let me know if there is anything more I can
provide to address this issue.
Jamie.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 7 22:12:37 2003