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

On Tue, Aug 5, 2008 at 6:49 AM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
> 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.

I have no general objections to using Zest. Especially if it makes
the code easier. One small concern is what impact this has on the
versions of Eclipse we can support. Does Zest fully support Eclipse
3.2? I'd hate to not support Eclipse 3.2 users at all with this
feature. Does it drag in any dependencies we need to be aware of? I
do not think so.

> * 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.

To get the information you need to just specify true on
includeMergedRevisions when getting the log data. This will make the
overall API slower, but is probably worth it. What happens is that
when the callback receives a revision that is a merge, it then starts
getting callbacks for the revisions that were merged. If any of those
were merges, then those come to the callback. So you will need to
handle all of this. You can look at the SVNLogMessageCallback class
to see how we have done this. For your purposes, I suspect you will
just want to discard all revisions you get after the first level of
merges. This is because your "database" will already have information
on the other revisions.

As you look at revising the visualization, I'll remind you of this:

http://trac-hacks.org/wiki/RevtreePlugin

Since it shows the merge information it would be worth looking at as
an example. I also like how it "reverses" the revisons so the newest
are on top.

-- 
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