C. Michael Pilato wrote:
>"C. Michael Pilato" <email@example.com> writes:
>>Ben Collins-Sussman <firstname.lastname@example.org> writes:
>>>In svn 1.0, 'blame' was about 100x slower than CVS. In svn 1.1, it's
>>>about 10x slower. I really can't think of any way to make it faster,
>>>other than doing what CVS does: keeping a cache of contextual diffs on
>>>the server, so the server can instantly generate annotation. We
>>>should probably start a different thread on this, to discuss (A) if we
>>>want to open an issue for this, (B) if/how we want to prioritize this
>>>enhancement at all.
>>CVS does keep contextual diffs, but we wouldn't need to store all of
>>that. All we'd need to store is what we actually want -- annotation
>>information. The username, date, and revision are stored as
>>revprops. All we lack are the line numbers, really.
>Sorry, I mispoke. I think we need line ranges and operation types.
>Like, "insert 5 lines at line 14", "remove lines 21-37", etc. The
>point being, we don't actually need to know the contents of the lines.
Exactly. libsvn_diff could be taught to compute this info quite easily,
and the server could do it at each commit. Since we already have the new
and old fulltext on hand for deltification, this wouldn't be too much
extra trouble. If you do it right, you can do the blame calculation from
newest to oldest, and can chop it off as soon as all lines in the
current file are accounted for.
Of course, we'd have to figure out what to do about files that change
from text to binary (or back) throughout their history...
>Now, I say that assuming we want to keep svndiff as our primary delta
>storage format. But I'm open to considering a system that stores
>svndiff for some files and contextual diffs for others.
Oh, no. I think svndiff + blame info would still be more compact on
average than any kind of context diff.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Wed Nov 17 23:02:27 2004