I'm a student from Spain. I've developed applications with Java since its 1.1 version. My favourite IDE is Eclipse and Subversion is my choice for versioning projects.

I’m very interested in the opened issue in subclipse about developing a revision graph. I always put a special effort on making intuitive and easy to use applications. I think it's very important because is one of the things that makes an application being useful. I'm also very interested on performance and scalability. This task requires to handle a lot of information from the subversion server and I think that making a fast and optimal mechanism for handling that information is a nice challenge. I also like this task because providing a revision graph for subclipse will be a big step forward for Eclipse and Subversion, two of my favourites tools in software development and would be well-received by the community.

I have big experience on software development and deep experience using development tools like Eclipse, Subversion and others (JUnit, Ant, Maven…). I have also used SWT and GEF libraries, so I think I am a very good candidate for this task.

I'm finishing my studies on computer engineering. During these studies I've also been working in some companies (some big companies such as Ericsson and Vodafone) and now I'd like to work on group in an open source project. Participating on GSoC 2008 will provide me a great experience. I’m very passionate about this. And I think I can also provide great things to this project.
 
Talking about the technical details of this task I find the big challenge in this task in making a local cache of the information fetched from subversion and developing an algorithm to create the graph from that information. The need of a local cache is obvious for many reasons. Having a local cache will provide the hability to see revision graphcs even when you are off-line. Also you reduce the amount of information fetched from the server each time you want to see a revision graph. In fact the first time you'll have to request a big set of information. But in the future you'll just query for updates.

In order to develop the cache my proposal is to use an embedded database like Apache Derby / JavaDB. As I explain in the detailed description I've planned a database structure that let fetching the history of a file in two very simple queries. The algorithm for building the graph is very simple and works directly with the result of those queries.