On Sun, 21 Nov 2004, [UTF-8] Branko Ä^Libej wrote:
> Peter N. Lundblad wrote:
>
> >On Sun, 21 Nov 2004, [UTF-8] Branko �^Libej wrote:
> >
> >
> >>No, we already know at least two ways to get the information we want.
> >>One way is already being used by "svn blame" -- it interprets context
> >>diffs. Another way would be to extract the info from svndiffs (which is
> >>harder). A third way is to use the algorithm in libsvn_diff, but to feed
> >>it different tokens (e.g., bytes instead of lines).
> >>
> >>
> >>
> >Heh. It would be interesting to whach the performance of svndiff with
> >bytes as tokens.
> >
> >
> Yikes, more terminology problems. "libsvn_diff" and "svndiff" are
> different things.
>
I meant libsvn_diff. Sorry.
> >>What we need to figure out is how to encode this information in the
> >>repository so that a) it is compact, b) can be used to calculate the
> >>blame info bachwards in time instead of forwards, and c) can be
> >>interpreted by the client without knowledge about the generating
> >>algorithm. Storing a list of added and deleted byte ranges seems like a
> >>logical choice.
> >>
> >his would make the algorithm O(n). Storing, for each revision, range
> >added in revision X would make the algorithm O(1), so there is room for
> >discusssion.
> >
> >
> I must admit I understand every word in the above, but I haven't the
> faintest idea what it means...
>
It is the difference between having to consult the actual revision and
that revision and possibly everyone older than that revision.
> >Maybe we should take a step back and do some more testing before
> >
> No "maybe" about it at all.
>
Yes. I think it is time to file an issue for this so it can be addressed
when time permits. Anyone objecting that I add an "blame performance"
issue?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Nov 21 21:39:17 2004