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 firstname.lastname@example.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.
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.
Click here for a list of all open issues in our issue tracker with the "SoC" keyword applied.