Philip Martin wrote on Wed, Nov 16, 2011 at 17:31:12 +0000:
> "Daniel Shahaf" <d.s_at_daniel.shahaf.name> writes:
>
> > On Wednesday, November 16, 2011 5:06 PM, philip_at_apache.org wrote:
> >> Author: philip
> >> Date: Wed Nov 16 17:06:50 2011
> >> New Revision: 1202783
> >>
> >> URL: http://svn.apache.org/viewvc?rev=1202783&view=rev
> >> Log:
> >> * subversion/libsvn_fs_fs/fs_fs.c
> >> (rep_write_contents_close): Log root cause, rather than a generic error,
> >> when failing to open rep-cache.db.
> >>
> >> Modified:
> >> subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
> >>
> >> Modified: subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c
> >> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c?rev=1202783&r1=1202782&r2=1202783&view=diff
> >> ==============================================================================
> >> --- subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c (original)
> >> +++ subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c Wed Nov 16 17:06:50 2011
> >> @@ -5600,7 +5600,7 @@ rep_write_contents_close(void *baton)
> >> /* Something's wrong with the rep-sharing index. We can continue
> >> without rep-sharing, but warn.
> >> */
> >> - (b->fs->warning)(b->fs->warning_baton, err);
> >> + (b->fs->warning)(b->fs->warning_baton, svn_error_root_cause(err));
> >
> > Disagree. This just loses information. The implementation of
> > svn_fs_warning_func_t in mod_dav_svn should call
> > svn_error_root_cause() if it so chooses, but let's not prevent the
> > chain from callers who care about it.
> >
> > Accordingly, -0 to backport.
>
> 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.
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).
Received on 2011-11-16 19:35:54 CET