Stefan Küng wrote:
> Nikolaus Bates-Haus wrote:
>> Our subversion repository currently has over 72000 (seventy two
>> thousand) revisions, and probably has around 500000 (five hundred
>> thousand) files and directories (considering each branch of a file to be
>> a separate beast).
>>
>> When I right-click on a file in my sandbox (even a file for which the
>> log shows only e.g. two revisions) and select "Revision graph",
>> TortoiseSVN dutifully retrieves all 72000 revisions (takes ~1 minute),
>> then churns for ever more (well, I let it run for a couple of hours on
>> my dual 2GHz Xeon w/ 4G RAM). In that time, its VM size went from 200MB
>> up to 270MB, and was continuing to grow slowly.
>>
>> I understand that TortoiseSVN is trying to reconstruct data from the
>> full revision history, and that this involves multiple passes and
>> parsing and whatnot. What I'm wondering is whether the revision graph is
>> *supposed* to be able to handle this use case.
>
> It *can* handle it, but as you discovered, it's just way to slow.
> There's nothing I can do about that - I've tried to optimize that code
> part already and it *is* much faster on trunk. But that's as good as
> it might get.
>
> Stefan
>
Hi Stefan.
After the avalanche of black dots down the screen from the last episode,
dare I ever post again?
Would there be any virtue in maintaining a checksummed copy of the log
history in the WC .svn protected area and just update it at opportune
times. Then at graph generation time use that instead of going to the
server for more than getting any late changes and doing a cross check
with the checksum.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: users-help@tortoisesvn.tigris.org
Received on Thu Apr 13 16:16:03 2006