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
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.
Alberto Gimeno Brieba
Presidente y fundador de
Ribe Software S.L.
página web: http://gimenete.net
teléfono móvil: +34 625 24 64 81
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 13:51:23 CET