[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [Subclipse-dev] GSoC coding

From: Alberto Gimeno <gimenete_at_gmail.com>
Date: Wed, 28 May 2008 19:42:17 +0200

Hi again.

As I told you I'm planning to implement the cache as the first thing.

I think I should create a database for each project that uses this
plugin. And this will be the database structure:

Since files can be moved and copied I think an internal "file_id"
should be used instead of a "path". There will be a "files" table that
will assign a "file_id" for each "path" in each revision. Well, the
table could be enormous and redundant. So I'm going to create a table
that stores that information only when the path changes (when a file
is moved or copied/branched). I'm going to use four columns:

* file_id // internal identifier
* revision_from
* revision_to
* path

This table let us know what file_id has a certain "path" in a certain revision.

I'm going to use two more tables. One will store the information about
the log messages. "revisions" will store the information of
LogMessages and "change_paths" will store the information of
ChangePaths. And those tables will also store the internal identifier
(file_id) in a way that the history of a given file will be fetched in
one query.

                String s = "CREATE TABLE files (" +
                                "file_id BIGINT NOT NULL, " +
                                "revision_from BIGINT NOT NULL, " +
                                "revision_to BIGINT, " +
                                "path VARCHAR(32672) NOT NULL)"; // no primary key
                
                executeUpdate(connection, s);

                s = "CREATE TABLE revisions (" +
                                "revision_id BIGINT NOT NULL, " +
                                "revision_date DATE NOT NULL, " +
                                "author VARCHAR(32672) NOT NULL, " +
                                "message VARCHAR(32672) NOT NULL, " +
                                "PRIMARY KEY (revision_id))";

                executeUpdate(connection, s);

                s = "CREATE TABLE change_paths (" +
                                "path VARCHAR(32672) NOT NULL, " +
                                "revision_id BIGINT NOT NULL, " +
                                "copy_src_revision BIGINT, " +
                                "copy_src_path VARCHAR(32672), " +
                                "action CHAR(1) NOT NULL, " +
                                "file_id BIGINT NOT NULL, " +
                                "PRIMARY KEY (path, revision_id))";
                
                executeUpdate(connection, s);

                s = "ALTER TABLE change_paths ADD CONSTRAINT fk_change_revision " +
                                "FOREIGN KEY (revision_id) REFERENCES revisions (revision_id)";
                
                executeUpdate(connection, s);

                s = "CREATE INDEX files_revision_from ON files (revision_from)";
                
                executeUpdate(connection, s);

                s = "CREATE INDEX files_revision_to ON files (revision_to)";
                
                executeUpdate(connection, s);

                s = "CREATE INDEX files_path ON files (path)";
                
                executeUpdate(connection, s);

                s = "CREATE INDEX files_file_id ON files (file_id)";
                
                executeUpdate(connection, s);

So, the next step will be to create a "persistence tier" for these
tables. I mean a data access object with a method to query the
information for a given file and methods for inserting data fetched
from the SVN server using "svn log". I will test those methods with
dbUnit. I attach a file with an example XML file for testing purposes.
I have used the example data I found here:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.using.html#svn.branchmerge.using.work.dia-1

I think we could define an interface for that object so we could have
several cache implementations.

I'm looking forward your comments.

Regards.

On Tue, May 27, 2008 at 4:41 PM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
> Ok. So I will create a new plugin. Called
> org.tigris.subversion.subclipse.ui.graph for example? Or maybe two
> plugins: org.tigris.subversion.subclipse.ui.graph and
> org.tigris.subversion.subclipse.cache
>
> As I explained in the proposal I think the best will be to use an
> embedded database for the cache. So the first thing I think I'll do is
> to create a persistence tier to save the log information fetched from
> the SVN interface using JDBC. This is: create a database structure as
> I explained in the proposal. I can test this part making JUnit tests
> and using example log information for different repositories. I will
> probably use DbUnit that is an extension of JUnit and I have
> experience with it.
>
> Next I want to add an "action" to the context menu. Just below the
> Team -> Show History... submenu. This action will perform these steps:
> * update the cache information if it needs to be updated. Communicates
> with SVN and saves the information in the embedded database.
> * query the needed information to build the graph. Makes two queries
> against the embedded database.
> * build and show the graph.
>
> The first two steps need the persistence tier. The third step at first
> won't show a graph. Instead it will dump the information as plain
> text, just to see if the cache is working as expected. When I have the
> cache finished I will work in the graph: learn about GEF, choose a
> graph layout,...
>
>
>
> On Tue, May 27, 2008 at 4:13 PM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Tue, May 27, 2008 at 10:05 AM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
>>
>>> According to the GSoC timeline the coding period started yesterday. To
>>> start coding I think the other student and I should have a branch in
>>> the repository.
>>
>> It would be best to create it as late as possible. You should just be
>> able to switch your trunk checkout to the branch and commit when
>> needed.
>>
>> I'd much rather see discussion about what you intend to do. For
>> example, in your case the UI for the task is definitely going to go
>> into a new plugin so that we can make the dependencies it drags in
>> optional. We might just do it all in new plugins, but I could
>> potentially see some of it going into our core plugin.
>>
>> --
>> 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
>>
>>
>
>
>
> --
> 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
>

-- 
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-05-28 19:42:28 CEST

This is an archived mail posted to the Subclipse Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.