Until now the graph was shown in a sepparate window. Now I’ve integrated it as an Eclipse View.
Also, now the code runs as a background task. Thanks to Steve Elsemore 🙂
Posts Tagged eclipse
The cache design
The biggest challange in my GSoC project is the design and implementation of a cache system. Why a cache system is needed? For two reasons:
- To show the revision graph of a file I need a lot of information. If the file is at revision 123 I need to ask the repository for its history from the base revision to the 123th revision. Next time, suppose the file is at revision 234, so I’ll need to ask the repository for its history from the base revision to the 234th revision. But, I’ve asked twice for the information from the base revision to the 123th revision. This is, the information I asked will never change. I should only ask for updates.
- The second reason is the most important one. There is no way to ask SVN for the whole revision history of a file. I mean, its history and the history of its branches. If you ask for /trunk/Foo.java, SVN won’t tell you anything about its branches. If you ask for /branches/2.x/Foo.java SVN won’t tell you anything about other branches or changes in /trunk/Foo.java since the 2.x branch was created.
So what to do? The solution appears to be building a cache system. The cache will store information previously asked and also will store the information about branches in order to query easily for the whole history of a given file.
My cache design is based in an embedded database (Apache Derby) with the following structure.
The “files” table
I’ve decided to give a unique ID to each file. The same ID is shared with all its branches. So /trunk/Foo.java and /branches/2.x/Foo.java have the same ID. This table tells you for example:
/trunk/Foo.java was added in revision xxx, deleted in revision yyy and has the ID 123
With this table you can ask for exmple
Which ID has the file /foo/bar.c in revision 123?
And when you get the ID of a file you can ask for all its branches and when they were created.
The other tables
There are other two tables: revisions and change_paths. These tables just store all the log information: author, revision number, date, action,…
The algorithm
When someone wants to see the graph of a file. I follow these steps.
- Fetch all the log information from the repository. Or only the updates from the last revision that was stored in the cache.
- Store the fetched information in the cache. Calculating IDs and branches.
- Query the cache for the *whole* history of a file. This is a simple query: Give me all the log messages of the file with ID xxx.
The problem is that the first two steps can be high time comsumption tasks. But in my opinion the big goal is to make the third step as fast as possible. As I learnt in database design the queries are the most important. However I’ve thought about possible changes to improve performance.
Possible alternatives
To only use the “files” table. Storing just the branching information will make the cache smaller. With the information of this table you know when files were added, deleted and branched. The information about authors, comments, dates and M (modify) actions will be fetched on demand. This approach could have two steps. First building a simple graph with the branches and then the information about authors, comments,… could be loaded asynchronously.
To only store the log messages of selected files. This is, not to store all log messages but only the log messages of those files that are required to show the graph. This is the same than the previous approach but storing the log messeges once they have been fetched from the repository.
These approaches make the cache smaller. But they need to connect to the repository several times. I will only change my main approach to one of these if queries are slow.
My focus now is to resolve some bugs and improve the graphical part. This is, I want to integrate the graph into an eclipse view / editor and make it work with small but real-life repositories. I also want to show a progress bar while the cache is fetching information from the repository or while is calculating the IDs and branches.
Setting up the environment
These are the steps I took to have my environment ready for coding.
- At first you need to checkout the subclipse code. Here you’ll find instructions about accesing the source code repository. Use ‘guest‘ for username and password.
- Make a clean installation of eclipse. Since sublicpse is a plugin for Eclipse I downloaded Eclipse Europa for RCP/Plug-in Developers.
- Sublicpse itself is also needed. So install it.
- Import the projects under trunk/subclipse with File -> Import… -> General / Existing Projects into Workspace. Then choose the trunk/subclipse folder.
- The build of the project org.tigris.subversion.clientadapter.svnkit will fail, but it doesn’t matter. SVNKit is pure Java library for accessing SVN repositories. By default (at least in Windows) JavaHL is used instead. You can change this in the preferences page: Window -> Preferences -> Team / SVN.
Once I set up the environment I made some changes in the source code and I tested it. I think the easiest change is adding a component in the preferences page. The source code for the preferences page can be found in the org.tigris.subversion.subclipse.ui.preferences.SVNPreferencesPage class. I added the second line in this example code:
showCompareRevisionInDialog = createCheckBox(composite, Policy.bind("SVNPreferencePage.showCompareMergeInSync"));
createCheckBox(composite, "foo bar");
Now you need to test that this code works. To do this open the plugin descriptor file (plugin.xml) for the org.tigris.subversion.subclipse.ui project. You’ll see an editor pane with many tabs at the bottom. In the default tab (Overview) there are two options for Testing: “Launch an Eclipse application” and “Launch an Eclipse application in Debug mode”. Click one of them. A new Eclipse application will be launched with your code changes. Now open the SVN Prefrences Page to see the changes.
Gimenete on Google Summer of Code