"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.
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com
Received on 2011-11-16 18:38:50 CET