[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Unable to dump repository

From: Tony Thompson <Tony.Thompson_at_stone-ware.com>
Date: 2007-03-16 22:38:48 CET

Some more information about configuration and how the repository got
into this state. We are using SVN through Apache with the SVN modules.
We have a reverse proxy server sitting in front of the Apache server and
are using the Tortoise client on developer workstations. Apparently the
proxy server was the source of the corruption. I was able to go
directly to the Apache server and not corrupt a new repository and also
through another proxy and not corrupt the repository. So, a reboot of
the proxy seemed to clear matters up.
But, that concerns me a bit. To get it to corrupt, I could add 3 files
to my working copy and use the tortoise client to commit them. It
reported back that the three files had been committed but a check of the
repository with the Tortoise repo browser showed that only two files
were in the repository. I could not find any errors in the Apache
access or error log that would indicate there was an issue committing
Since the reboot, I can't reproduce the issue anymore so hopefully with
that info and the bad repository I sent someone can come up with a good


From: Mark Phippard [mailto:markphip@gmail.com]
Sent: Thursday, March 15, 2007 3:22 PM
To: Tony Thompson
Cc: users@subversion.tigris.org
Subject: Re: Unable to dump repository

On 3/15/07, Tony Thompson <Tony.Thompson@stone-ware.com> wrote:

        On 3/15/07, Tony Thompson < Tony.Thompson@stone-ware.com
<mailto:Tony.Thompson@stone-ware.com> > wrote:

                It does tell me what the last revision number was that
it dumped but, there is lots of stuff in the repository after that
revision that I don't want to lose.


        I have never had to recover a problem like this. If you can
dump up to the problem, then skip that revision and dump what comes
after, you might be able to fix the problem. Just load the first dump
file. Do some random commit to use up the next revision number, and
then load the second dump file. The random commit is not strictly
necessary if you do not care about the revision numbers changing.
        It appears that there are other revisions after my corrupt
revision that also have that same issue. It would be nice if there was
a repair option that could just fix it for me :) ... but that would be
too easy. I can dump pieces of the repo so I will work on piecing it
back together from that unless someone else has any better suggestions.

Would you be willing to make the repository available for some
post-mortem? The upside for you is that perhaps a developer could fix
it by hand. The upside for us would be fixing a potential problem.

Is this fsfs or bdb? Have you done anything to muck with any of the
files in the repository directly?

Mark Phippard
This message (and any associated files) is intended only for the 
use of the individual or entity to which it is addressed and may 
contain information that is confidential, subject to copyright or
constitutes a trade secret. If you are not the intended recipient 
you are hereby notified that any dissemination, copying or 
distribution of this message, or files associated with this message, 
is strictly prohibited. If you have received this message in error, 
please notify us immediately by replying to the message and deleting 
it from your computer. Messages sent to and from Stoneware, Inc.
may be monitored.
Received on Fri Mar 16 22:39:09 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.