On Thu, Mar 20, 2008 at 5:51 AM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
> I'm a student from Spain interested on working in the opened issue
> about developing a revision graph for subclipse.
>
> I agree that the biggest issue is fetching all the information needed
> to draw the graph. I think this should be achieved using some kind of
> cache. I think that using an embedded database like Apache Derby would
> be a good solution. Derby has a small footprint: about 2 megabytes for
> the base engine and embedded JDBC driver. And Derby also has an
> Eclipse plugin (http://db.apache.org/derby/integrate/plugin_howto.html).
> I'll investigate about what would be better: make a dependency on the
> Eclipse plugin for Derby or use the Derby jar files as part of the
> subclipse plugin.
>
> About the fetching process: I think it should be ran in background. In
> the same way Eclipse indexes the content of text files. Then when the
> user wants to see the revision graph the plugin makes a request for
> newer changes if any in order to have the cache up to date. Finally
> the graph is drawn. Maybe it would be interesting first to draw the
> graph with the information in the cache, ask for changes and if there
> are newer information then redraw the graph. In this process the user
> should be informed that the plugin is asking for new information and
> the graph is seeing may lack some information. This aproach will
> provide a fast response to the user and the ability to see the graph
> if it is not possible to connect to the subversion server in that
> moment (i.e. the internet connection is down).
>
> The embedded database will consist in a table storing the information
> of changes: revision, file/folder path, type of change (file/folder
> adder, file/folder deleted,...) and any other information required.
>
> Waiting for your opinions and suggestions.
I have tried to store path information in a database structure before
and it is not always as simple as it sounds. Does the database allow
the field to scale to any length path? How do you query the data
intelligently? Do you try to recreate a tree structure in the
database etc. For example, if I make a branch, I will have a revision
that says I created /branches/branch from /trunk. When I am viewing
the history of a file from trunk, I need to know that database record
is significant etc..
I only point this out to say there are additional complications you
need to plan for if you go down this road. I would strongly suggest
anyone that does this look at what TortoiseSVN has done for their
cache, and how do they use it.
Part of me has been wondering if a low-tech solution might not work
just as well. For example, what if we based the feature off of our
existing subclipse:tags property?
http://subclipse.tigris.org/branch_tag.html
It would not be a perfect solution, but it would probably perform well
and could in some cases be better that a "real" revision graph because
it would be easy to exclude "noise" by not configuring it in the
property,
--
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
Received on 2008-03-20 16:17:39 CET