[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: Wed, 16 Nov 2011 20:35:10 +0200

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

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.