Re: [Subclipse-dev] GSoC coding

Alberto,

I cannot recall if I replied to this. In general it looks good.
Until you are really doing it, it will be hard to know. You might
also look at the same repository that is here:

http://merge-tracking.open.collab.net/servlets/ProjectProcess?documentContainer=c2__Sample%20repository

There is a dump file you can load for testing.

I am also a committer for Subversion, and am busy trying to get 1.5 to
final release status. So sorry for not replying in more details.

Mark

On Wed, May 28, 2008 at 1:42 PM, Alberto Gimeno <gimenete_at_gmail.com> wrote:
> 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
>

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