You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Basil James Whitehouse III <ba...@sympatico.ca> on 2003/07/07 19:55:23 UTC

broken repo

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