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.
>> This brought me to thinking that the same system on a server could be
>> efficient and speedy for users.
>>
>> So, what do think the chances are of running the Subclipse graphing code
>> on a server-side installation, abstracted from the rest of
>> Subclipse/Eclipse?
>>
>> The cache would be global, and nodes could be rebuilt on a post-commit
>> trigger.
>>
>> So, what do you think?
>
> It really isn't a viable idea for a general purpose product. There
> would just be too many pieces for someone to put in place to use it.
> You need hook scripts to build the data, You need a server and some
> kind of protocol to serve it to the client. If your repository is on
> tigris or Google Code or sf.net how could you use this?
I guess you might be right about this - I realise that I hadn't
specified the type of server use I had envisaged, which was a web server
component akin to perhaps cvsgraph.
Considering this as the simplest use-case (Java tool providing a PNG
image and optionally image map information), you'd still need to:
* Abstract the caching and log retrieval
* Abstract the building of the graph and conversion to a bitmap format
* Be able to build image-map information for the nodes in the bitmap
* Write a postcommit hook script to update the cache.
So, quite a few pieces. :/
> The only solution beyond caching is that we need Subversion itself to
> grow this feature somewhat more natively. Basically, be able to ask
> Subversion for this information and let it calculate the information
> from its repository and provide it back. Until then, I think we are
> stuck with custom caches.
Well, that is certainly the truth - without "copy to" information in the
repository, caches are a necessity for any graphing functionality. I was
just wondering if any existing work/code could be utilised to give web
SVN repository viewers the functionality that I find them all lacking -
revision graphing.
John.
--
John Beranek To generalise is to be an idiot.
http://redux.org.uk/ -- William Blake
------------------------------------------------------
http://subclipse.tigris.org/ds/viewMessage.do?dsForumId=1043&dsMessageId=1075926
To unsubscribe from this discussion, e-mail: [dev-unsubscribe_at_subclipse.tigris.org].
Received on 2009-01-30 19:33:25 CET