Re: MT 'blame' and 'log' Auditing - Design Specification

On 28/04/2007 19.30, Mark Phippard wrote:

>> > I object to the two additional columns. If I run svn blame
>> > --merge-sensitive I do not need to see any other information. I
>> > thought at one point we even said that were it not for the expected
>> > performance hit in getting the merge information that svn blame should
>> > just always return this information. When using blame it is not
>> > likely that someone would want any other information.
>>
>> +1 here. And I still don't agree for it not being the default. I still
>> wonder
>> who exactly worries about svn blame's performance (especially when
>> compared
>> with correctness).
>
> I believe blame performance is a huge issue to the gcc and kde
> developers. dannyb made a lot of improvements to the performance so
> that those projects could switch to svn.

IIRC, the problem with GCC was only with ChangeLog files (does anybody blame
ChangeLog files for real?) and anyway it was an asymptotic performance issue
with the blame algorithm which was resolved.

> dlr things that the performance hit here could be pretty substantial.

Well possible, but I wonder about the tradeoff. Do we have numbers? Is it much
slower also for files which don't have any merge information (that is, it
affects also people not using branches at all, or not merging so often)?

-- 
Giovanni Bajo
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org