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

Re: svn commit: r1202783 - /subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c

From: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Thu, 17 Nov 2011 00:47:22 +0200

Philip Martin wrote on Wed, Nov 16, 2011 at 18:56:56 +0000:
> Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
>
> >> fs_fs knows that in this case the root cause is important and that the
> >> error chain is mostly useless. mod_dav_svn, and svnserve, cannot know
> >> that so would have to print the whole chain in every case.
> >
> > "In this case"? How do you know what the case is? It might be a disk
> > problem, not just the specific error that triggered your fix.
>
> Getting the rep from the rep-cache database failed. The root error is
> the one that matters, whether it is "permission denied" or "wrong sqlite
> version" or "i/o error". Recording "failed to open database" is not
> useful.
>

On the other hand, recording "Permission denied" without also recording
that it's related to the rep-cache DB, or to a particular rev file, is
also an instance of removing relevant information.

I suggested on IRC to make the code record the complete error chain.

> > Should we add some SQLite error code to the if() condition whose else()
> > branch you patched? For example, "SQLite db is corrupted" would appear
> > to be serious enough (if it's not already caught by the
> > SVN_ERR_FS_CORRUPT check).
>
> That branch doesn't clear the error, I assume it gets handled elsewhere.

Pretty much nothing catches SVN_ERR_FS_CORRUPT and assertion errors, so
I expect errors caught in the if() branch propagate all the way to
mod_dav_svn, if not to mod_dav itself.
Received on 2011-11-16 23:48:16 CET

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

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