When a project is connected to an SVN repository, a Team pop-up menu in the Package Explorer and Navigator views will show all Subversion-specific actions. You can directly run Commit, Update, Add to svn:ignore, and other actions as described in the Version Control with Subversion book. The content of this book is also available as part of the Eclipse help system at Help -> Help Contents -> Version Control with Subversion.
The Subclipse plug-in also allows the use of Eclipse's Team Synchronize view, which can give a good overview of what is going to be committed and what has been changed by other developers and needs to be updated from the repository. Most of the SVN commands can be also executed from this Synchronize view.
To add a project or working set to the Synchronize view you can use the Team -> Synchronize with Repository pop-up menu or Synchronize... wizard button located on a main toolbar. If you can't see this button, then Team commands should be added to the current perspective; you can add them using the Customize Perspective dialog available from the pop-up menu on the main toolbar (click any empty space), and then save the perspective under the same name using the Window -> Save Perspective As... menu.
Figure 11. Add command groups to the current perspective.
Choose the Synchronize... action in the toolbar drop-down to start the wizard. On the first screen it again allows you to select the SVN version tracking system and then shows the standard resource selection panel, where you can choose to synchronize an entire workspace, select some set of projects, or use a named Working Set.
Figure 12. Synchronize a workspace, working set, or selected resources.
Once created, the Synchronize view can schedule an automatic refresh with the version control system. This can be configured from the Schedule... menu in a Synchronize view menu. This will help you stay up to date, and allows you to see all incoming changes from other developers.
Figure 13. Schedule automatic refreshes.
Since Subclipse is still evolving, there is a chance you'll run into a bug, or you won't find some features you really want. This brings us to the next topic.
When you run into issues in Subclipse you have several choices. If the issue is a showstopper you can simply decide not to use the product, or wait for the next version. You can also search through the issue tracking system and the mail list archives and with some chance of finding a workaround or explanation of what you are doing wrong. If that does not help, you can politely ask in the mailing list about the issue. If you are interested in trying to solve the problem yourself, then the following paragraphs will give you a brief introduction in how to start debugging and patching Eclipse. However, if you have a serious intention to contribute, it is a good idea to subscribe to the mailing list to coordinate your efforts with other developers and align your ideas with the project roadmap.
It is really easy to get started, even if you haven't worked on an Eclipse plug-in before. You'll need to get Subclipse projects into the Eclipse workspace. The Subversion repository for the Subclipse project is located at http://subclipse.tigris.org/svn/subclipse/, and you can either use a previously installed Subclipse plug-in or external tools such as a command-line Subversion client or TortoiseSVN to check out the code. It is also a good idea to register on the tigris.org Web site and request an Observer role for the Subclipse project. Then you will be able to use the same user name to connect to the Subversion repository ("guest"/"guest" also works fine for read-only access), and you will also have permission to comment on issue tracker (an integrated Bugzilla repository) as well as attach patches to issues (if you've made any).
Once connected to the version control repository you'll need to check out the following projects into your workspace. For each module select Check Out As..., choose a location and project name (I recommend to use the actual plug-in names as in the following table), and click Finish.
|Repository Path||Jar or Eclipse Plug-in Name||Description|
|trunk/svnClientAdapter||svnClientAdapter.jar||For non-Windows or when you need to build svnClientAdapter or JavaHL|
|trunk/subclipse/core||org.tigris.subversion.subclipse.core||Eclipse-specific plug-in backend|
|trunk/subclipse/javahl-win32||org.tigris.subversion.javahl.win32||Prebuilt native Windows binaries for svnClientAdapter and JavaHL|
|trunk/subclipse/feature-plugin||org.tigris.subversion.subclipse||About. No code|
|trunk/subclipse/feature||org.tigris.subversion.subclipse (feature)||Subclipse feature|
|trunk/subclipse/book||org.tigris.subversion.book||Eclipse help section with "Version Control with Subversion" book|
|trunk/subclipse/book-feature||org.tigris.subversion.book (feature)||Feature for "Version Control with Subversion" book|
|trunk/subclipse/update-site||-||Update site for Subclipse and "Version Control with Subversion" book features|
For development and testing you'll need only
org.tigris.subversion.subclipse.ui, and either
svnClientAdapter. Other modules are required only to package a complete plug-in feature or build an update site.
When all the projects are in your Eclipse workspace, you can try to run it. Use the Run -> Run... menu (or Debug to run under debugger), create a new launch for an Eclipse Application type, and select the Subclipse plug-ins from the Workspace Plug-Ins list. If you are running an IDE with an installed Subclipse, then you should also uncheck the Subclipse plug-ins in the External Plug-Ins list, but keep all other plug-ins selected.
Figure 14. Run the Eclipse application.
Click Run (or Debug), and if everything has been configured correctly you'll get a second Eclipse Workbench window; you should be able to open Subclipse views and connect to repositories as with the main Eclipse instance. At this time, if running under debugger you can start putting breakpoints in Subclipse classes or Eclipse core classes used by Subclipse, and the debugger will stop on those breakpoints. A good starting point is the
org.tigris.subversion.subclipse.ui.actions package in the
org.tigris.subversion.subclipse.ui plug-in, which contain Subclipse-specific UI actions available in menus or toolbars. Note that actions can be registered with the UI either declaratively in
action element) or programmatically in the Java code, so you have to look in both places.
Assuming the tricky part is done and you've managed to implement your changes, it's time to create a patch and attach it to an original issue in the Subclipse issue tracking repository. Before creating a patch, make sure to pick up the most recent changes (if there are any) from the version control repository and test your changes for the last time. If everything is okay, then use the Team -> Create Patch... menu to start the wizard. Select Save To Clipboard or Save In File System, and specify if you need subdirectories to be recursively scanned for the changes.
Figure 15. Create a patch.
Once the patch is created you can send it to the firstname.lastname@example.org mailing list, or create an issue in the issue tracker and attach it there.
Open-source extensions to the Eclipse platform, such as the Subclipse plug-in, can increase developer productivity, reduce the possibility of making mistakes, and improve communication within a development team. This article has demonstrated how to install, configure, and use the Subclipse plug-in to interact with a Subversion version control system from within the Eclipse IDE.
Using the Subclipse plug-in as an example, the article also demonstrated how to set up an environment for Eclipse plug-in development, how to debug existing plug-ins, and how to create patches. Virtually any Eclipse user can contribute ideas and patches to the open-source extensions as well as to the Eclipse platform itself.
Eugene Kuleshov is an independent consultant. He has over twelve years of experience in software design and development and specializing in application security, enterprise integration (EAI) and message oriented middleware.