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

Re: Enhancing svn blame (Was: Case study: Mono switches to Subversion)

From: <kfogel_at_collab.net>
Date: 2004-11-20 01:09:01 CET

"Peter N. Lundblad" <peter@famlundblad.se> writes:
> I know you and others have been discussing blame caching on the server. I
> would say this is the usual tradeoff between API flexibility and speed:-)
> The problem with server support is that we hardcode the diffing algorithm,
> or at least removes the possibility to have other diff programs provide
> the blame information. We're not doing this today, but I don't like to
> move this to the server if we can avoid it. Also, we should consider other
> queries that are similar to blame, such as functionality to ask "who
> deleted this line"? (I've actually seen this requironment somewhere.) The
> problem with moving specialized functions to the server is that they have
> to be supported by all three (though one is trivial) access methods.

Throughout this thread, there has been a fundamental misconception
about how to implement blame caches on the server-side. I will now
grace you all with a revelation about the One True Way to do it.

/me pauses to preen himself

Okay, am I annoying enough yet?

Here's the thing: When you cache blame info on the server side,
*don't* store it in a line-based format. Store it as binary
difference ranges, that apply to all types of files, and *translate*
that to line-based information for line-based files when necessary.
The translation happens on the client side, not the server.

Binary differences can be composed just like line-based diffs. Blame
information is just as meaningful a concept with arbitrary ranges as
with lines. Line-based diffs are, after all, a specialization of
Platonic diffs. All blame calculations can be done in Platonic form
-- thus there is no need to favor one particular diffing algorithm on
the server side -- and the resulting information can be transformed
into line-based blame info for presentation to the user at the end.

By the way, if someone is tempted to wave this off with the "drive-by
proposal" epithet, I'll point out that

  a) Virtually every proposal in this thread has been devoid of
     technical details -- which is *fine*, there is an appropriate
     time to talk at a high level, and this is it. In other words,
     drive-by != evil.

  b) Sometimes one simple reconceptualization can have a big effect on
     how we think about a problem. I'm hoping this is that sort of


To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Nov 20 01:11:09 2004

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.