Login | Register
My pages Projects Community openCollabNet

Subclipse Ideas for Google Summer of Code

This page contains ideas for Google Summer of Code students. The items on this page are the ideas that we think would be the best projects for a SoC student and which would provide a lot of value to Subclipse. However, don't take these as gospel! We welcome discussion on creative proposals. Don't hesitate to ask for details or start discussing one of these tasks on the dev@subclipse.tigris.org mailing list (see here for subscription information).

In fact, please do discuss your task on the mailing list: regardless of whether you start discussing before or after submitting your application, a demonstrated willingness to engage with the rest of the Subclipse development community will be considered favorable in evaluating your application!

See the Subclipse Developer Guide for details on our policies and how to access the code.

Revision Graph

It would be useful if the history of a file or folder could be viewed as a revision graph. Eclipse, via the Graphical Editor Framework (GEF), gives us the tools we need to present a rich presentation of a revision graph. The challenge is really in Subversion, and what it would take to get the information we need to present a proper graph.

TortoiseSVN probably has the closest proximation of the feature we want to add and the challenges that will involve. Because of the amount of information they have to pull from the repository to create the graph, they created a local cache. We may need to do the same. Alternatively, we could work with the Subversion community to define the API's we need to get the information on demand.

Expected difficulty: Potentially High due to the Subversion limitations. This would be a very fun project though and would be well-received by our community.
Related Issue#: 721

Subversion 1.5 Changelists

Subversion 1.5 added support for a local changelist feature that is functionally very similar to the existing Subclipse change set support in the Synchronize view. This task involves tying the two features together so that a user can switch between Subclipse and the command-line or other tools and still see the changelist membership for a given set of files. The Subclipse change set support includes the ability to add folders to a change set, as well as associate a commit message. Those features cannot be lost.

Expected difficulty: Moderate. This is generally a straight-forward task but there will be a few areas where the two changeset implementations have differences that have to be worked out.
Related Issue#: 635

Implement Eclipse File System and History Provider API

Eclipse 3.2 introduced some new API and abstractions that are available for team and filesystem providers to implement. There are probably some internal simplifications we could make within Subclipse if we implemented these API, but the main benefit would be for third parties that want to build applications on top of these API's and have their application work properly for CVS, Subversion or any other tool that properly implements the API.

Expected difficulty: Easy/Moderate. Should be straight-forward, but will need to familiarize with the Eclipse API and might need to write a test app to really know the API's work.
Related Issue#: 513

Support Flexible Project Structures

Subclipse currently requires that the root of an Eclipse project be associated with a Subversion repository. Users have asked for more flexibility. For example, a project might have its src folder shared with Subversion, but not the project itself or its other folders. This feature would also allow us to make the checkout process more flexible as we could support checking out into existing projects. A common use-case is someone that wants to use Eclipse to work on a project that has not standardized on Eclipse and does not store the Eclipse project files in the repository. The user could create an Eclipse project locally, and then checkout the source code into that project.

Expected difficulty: Potentially High. A lot of code will need to be looked at and modified to not make any assumptions about the project structure. It is possible, perhaps even likely, that most of this code calls the same one or two methods though. So the core change might eventually involve a small amount of code. New UI would need to be added in places like checkout and share project to support this new scenario.
Related Issue#: 525

Rewrite Synchronize View to use new Logical Model API

In Eclipse 3.2 the CVS plug-in re-wrote their Synchronize view implementation to use a new API, called the Logical Model API. This allows alternate presentations of information in the view, such as Java-specific, generic resource, changesets etc. Presumably other "models" can be added easily or would automatically appear if present (such as a Ruby model). The main benefit for Subclipse, is to be supporting the new API. To the user, the presentation of their changes in the view closely matches the presentation from the model-specific views they are used to seeing.

Expected difficulty: Very Difficult. There is a lot of API involved, and in some cases it has not yet become full-fledged API which means code needs to be copied into Subclipse.

Other Ideas

Click here for a list of all open issues in our issue tracker with the "SoC" keyword applied.