Hi!
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?
(http://www.eclipse.org/gef/zest/).
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
own.
* 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
difficult.
>
> 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
