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

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

From: Daniel Berlin <dberlin_at_dberlin.org>
Date: 2007-04-29 04:47:03 CEST

On 4/28/07, Giovanni Bajo <rasky@develer.com> wrote:
> 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?)

No, it wasn't.
It was with any file with a large history.
Changelog took >30 minutes, but rtl.c took at least 10 minutes, even
though it's a very small file.
> and anyway it was an asymptotic performance issue
> with the blame algorithm which was resolved.
No, again, it wasn't.
The reverse blame changes were not committed.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Apr 29 04:47:29 2007

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.