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

Re: svn commit: r1166096 - in /subversion/trunk/subversion: include/svn_repos.h svnadmin/main.c

From: Hyrum K Wright <hyrum.wright_at_wandisco.com>
Date: Wed, 7 Sep 2011 08:34:50 -0500

On Wed, Sep 7, 2011 at 6:16 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: danielsh_at_apache.org [mailto:danielsh_at_apache.org]
>> Sent: woensdag 7 september 2011 12:20
>> To: commits_at_subversion.apache.org
>> Subject: svn commit: r1166096 - in /subversion/trunk/subversion:
>> include/svn_repos.h svnadmin/main.c
>>
>> Author: danielsh
>> Date: Wed Sep  7 10:19:32 2011
>> New Revision: 1166096
>>
>> URL: http://svn.apache.org/viewvc?rev=1166096&view=rev
>> Log:
>> Teach the svn_repos_notify_* interface to say "I won't repeat this warning
>> in the future".
>>
>> * subversion/include/svn_repos.h
>>   (svn_repos_notify_t): New member LAST_WARNING.
>>
>> * subversion/svnadmin/main.c
>>   (repos_notify_handler): Consume new member.
>
> Shouldn't the user interface (in this case svnadmin) be responsible for the suppressing of duplicate messages?
>
> Maybe a different client would want a different way of suppressing the messages.
>
> I can't think of a specific use case here,  but maybe something like counting the number of occurrences like we do with conflicts and skips in svn update.

+1

There is little harm in the libraries spitting out verbose warnings
unconditionally. Consumers should be able to filter them as desired.

-Hyrum

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Received on 2011-09-07 15:35:21 CEST

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