On Wed, Apr 29, 2009 at 12:17:34PM -0400, Andy Levy wrote:
>On Wed, Apr 29, 2009 at 11:53, Johan Corveleyn
><johan.corveleyn_at_uz.kuleuven.ac.be> wrote:
>> Thanks for the suggestions. Our clients are on Windows.
>>
>> I've played with TortoiseSVN, and it solves this problem very nicely (because it defaults to only getting the last 100 entries of the log (--limit 100), and offers buttons to get the next/previous 100). I don't know about the caching though (I'll check it out, also for SmartSVN).
>>
>> However, in our usual workflow this doesn't help much, as we use IntelliJ (Java IDE), with its integrated Version Control support (with SVN plugin through SVNKit). I guess I could try to contribute to IntelliJ (to the SVN plugin) to implement similar functionality as TortoiseSVN (i.e. --limit 100 and offer buttons to get more), or to load the history in the background and show it while it comes in. There are actually two IntelliJ issues open for this "improvement": http://www.jetbrains.net/jira/browse/IDEA-11092 and http://www.jetbrains.net/jira/browse/IDEA-22245. But I'd really, ultimately like this to be solved by the SVN server (all other solutions are patchwork).
>>
>> I guess the options are (in order of my preference):
>> - SVN server could be faster in retrieving this info
>> - SVN could implement caching on the client-side in its metadata (in wc-ng?)
>> - Maybe SVNKit could support some kind of caching client-side somewhere (??)
>> - Ultimately, the GUI client could take care of this, like TortoiseSVN or SmartSVN, and like maybe IntelliJ's SVN plugin should
>
>Is it possible that your server is I/O bound? Logs are stored in
>revprops, one per revision. So if you're pulling the history for a
>large range of revisions, you're doing a lot of access on many small
>files - some filesystems are very poor in this usage scenario.
>
Maybe unrelated, but I have seen (elsewhere) reports that depending on the version of SVNKit being
used, performance can be very sluggish for large repositories. For instance,
we recently upgraded our FishEye instance, and browsing performance improved
by at least an order of magnitude.
Received on 2009-04-29 18:29:22 CEST