Garrett Rooney wrote:
> On 1/31/06, Ben Collins-Sussman <sussman@red-bean.com> wrote:
>> On 1/31/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
>>
>>> It just seems like we should be going out of our way to make sure our
>>> users have trouble entering commands that seem simple at first glance
>>> but actually take a huge amount of time to complete.
>>>
>> I feel your pain. It makes me wonder if ... don't kill me for saying
>> this... if the results of a history-trace couldn't be cached in the
>> working copy somehow. It means the first time you run your diff
>> command (or other command that does history-tracing), it will be slow.
>> But if you ever run the same command (or similar command) on the same
>> path or URL again, the history data would be pulled out of the wc
>> cache instead. It would be safe to cache, because history is
>> immutable, after all.
>
> FWIW, at least half the time, maybe more, when I do this sort of thing
> it's from outside a working copy.
>
> -garrett
>
So uh, this shouldn't be slow anymore, anyway.
If it is, we probably missed somewhere we need to be using closest_copy.
Unless you really have a tree of 100k revisions where each revision is a
copy of the previous one or something.
In general, the history tracing should now be O(number of renames/copies
of file).
I'd start by seeing where we are going into a simple "walk every
revision backwards to find renames" loop, and fix it to use closest copy.
--Dan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Feb 1 19:06:01 2006