[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] Revision graph and cache implementation

From: Alberto Gimeno <gimenete_at_gmail.com>
Date: Tue, 5 Aug 2008 12:49:02 +0200


On Tue, Aug 5, 2008 at 2:11 AM, Mark Phippard <markphip_at_gmail.com> wrote:
> On Mon, Aug 4, 2008 at 5:40 PM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
>> I have changed the cache implementation to use files instead of the
>> embedded database. Now it takes about 3 seconds to build the graph in
>> a repository with 4k revisions (subclipse repository). The later
>> implementation took about 8 seconds. And I think I can make some other
>> minor improvements.
>> Additionaly this implementation doesn't require any initialization.
>> The embedded database needed 10 seconds just to get a connection.
>> With this implementation I've been able to build a graph of a
>> repository with 30k revisions (collab.net) without OutOfMemory errors.
>> This is how it looks zoomed out:
>> http://farm4.static.flickr.com/3099/2733530400_4e4b7defc0.jpg
>> I've committed the changes and I'm going to explain them in a post in my blog.
> Overall seems pretty good. The size of the "database" was cut in half
> too. Are you using the new callback-based log retrieval now?

Yes, I'm using it.

> What is your plan/roadmap from here? It seems like the overall
> presentation could still use some work. I do not find the output (the
> graph itself) terribly enlightening in most cases. There is just too
> much information. In general, I do not find the TortoiseSVN graph
> terribly useful either, but with all of the filters they have to cut
> down the information I have seen cases where it can be pretty good.
> Does using a custom database format make it more difficult if you want
> to store merge information later?

I'm going to focus on two things.

* Improve the output

What do you think of using Zest instead of GEF?
As I read here (http://www.eclipse.org/newsportal/article.php?id=20929&group=eclipse.tools.gef#20929)
GEF is more likely to be used for "editing" graphs and since the
revision graph is read-only Zest could be a better choice because is
focused on "visualization". And I see Zest is easier to use and nicer.
It has some layout algorithms and is also possible to implement your

* Plan to add merge information.

I need to take a look at the information returned by the repository to
plan how to add this feature. Anyway I think it won't be very

> Getting back to the presentation, I have also seen a lot of cases
> where there is incorrect information displayed. Usually a revision
> is just repeated multiple times. For example, I have a repository
> where I did a big import in r1. Then commited some sample changes in
> r2 and 3. If I look at a history of a file, I might see r1 listed
> several times, then see r2 and r3. I've seen similar duplication when
> looking closely at some of the diagrams from the SVN repository.

Yes I've seen that problem. I think I know why it happens and I can
fix it with simply an additional local variable in a method.

> Anyway, good progress. Looking pretty solid.

Thank you :)

> --
> Thanks
> Mark Phippard
> http://markphip.blogspot.com/
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
> For additional commands, e-mail: dev-help_at_subclipse.tigris.org

To unsubscribe, e-mail: dev-unsubscribe_at_subclipse.tigris.org
For additional commands, e-mail: dev-help_at_subclipse.tigris.org
Received on 2008-08-05 12:49:08 CEST

This is an archived mail posted to the Subclipse Dev mailing list.