On Thu, Mar 20, 2008 at 4:17 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>
> 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
>
>
When I need to store a tree structure in a database I use this
approach: http://www.sitepoint.com/article/hierarchical-data-database/2
The problem is that the table has to be rebuild when new nodes are
inserted. Because the two columns that store the information used to
place the nodes need to be recalculated.
I'm trying to know which approach they use in TortoiseSVN.
Here (http://tortoisesvn.tigris.org/tsvn_1.5_releasenotes.html) they
only talk about "TortoiseSVN 1.5 can cache the log entries on the
local drive".
And here (http://issues.tortoisesvn.net/?do=details&task_id=45) they
just talk about "log cache data structures" but they don't explain
wich kind of data structures they use and how they save them in the
local machine.
I'm going to continue investigating.
--
Alberto Gimeno Brieba
Presidente y fundador de
Ribe Software S.L.
http://www.ribesoftware.com
ribe_at_ribesoftware.com
Contacto personal
eMail: gimenete_at_gmail.com
GTalk: gimenete_at_gmail.com
msn: gimenete_at_hotmail.com
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 18:11:25 CET