"Daniel Shahaf" <d...@daniel.shahaf.name> writes: > On Wednesday, November 16, 2011 5:06 PM, phi...@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. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com
