On Fri, Jan 30, 2009 at 1:37 PM, John Beranek <john_at_redux.org.uk> wrote:
> John Beranek wrote:
>> Mark Phippard wrote:
>>> On Fri, Jan 30, 2009 at 10:50 AM, John Beranek <john_at_redux.org.uk> wrote:
>>>> I've been experimenting with the graphing functionality of Subclipse,
>>>> and it's rather good, albeit a bit slow to build the cache.
>>> I've actually been really happy with the performance. It is much
>>> better than I thought it could be. Obviously my repositories could
>>> just be a lot smaller than yours, but I only work on a slow DSL
>>> connection full-time. Building the cache of Subversion's repository,
>>> which is the biggest one I work with, is fast.
>> Well, I must admit we don't yet have a very big Subversion repository
>> yet - in fact we've not yet even switched to Subversion. However, if our
>> CVS repository is anything to go by (2 million file commits over >10
>> years making up a 350GiB repository) we will have a lot of revisions
>> very quickly if we switch.
> Hmm, count of file commits (from Bonsai) isn't perhaps the right
> guesstimate for Subversion-equivalent revisions. Over the life of the
> repository there have been "only" 430,000 different log messages, again
> according to our Bonsai database.
The original work on this feature stored the cache in a local Apache
Derby database. Performance of loading the cache wasn't so great so
we moved to a custom file format and saw great improvements. It might
be a cool piece of work for someone to take on to abstract the cache
and allow someone to plug a database back in. In a workgroup if you
could then point the location for your cache at a central database
server on your LAN, then you could all share the cache. Since the
burden of building the database would only be incurred once the
performance would probably be pretty good.
Just a thought. When the feature was initially designed we never
considered the idea of exposing access to the database and cache, but
it seems conceptually possible. And if the default cache provider was
still our custom local file format there would be no cost to users
that did not want to use this.
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-01-30 20:43:20 CET