Subversive brings Subversion to Eclipse
If you use the Eclipse development environment, you want it to mesh as seamlessly as possible with your version control system. If Subversion is your VCS, you've got a couple of options to help Eclipse play nicely with it and make regular commits a breeze. A previous article covered Subclipse; another alternative, with different strengths and weaknesses, is Subversive, which has been an official Eclipse project since 2007.
The best way to install Subversive is via the Eclipse update manager (Help -> Install New Software). Add it as an available software site, then choose it via the "Work with" box. You also need to install Subversive SVN Team Provider; the sources and the Integration plugin for the MyLyn project are optional. Finish the install process (if you have problems there are more details in the documentation), then restart Eclipse. On restart, you should see a dialog box asking which SVN Connector to install; you'll usually want SVNKit. Check whether you're using SVN 1.6.* or 1.7.* and choose the appropriate version of SVNKit; I used 1.3.7. If you have any problems, you can perform this step manually via the Eclipse update manager.
Once SVNKit is installed you can open the SVN Repository Exploring perspective from the perspective button on the top left of the Eclipse window – you may need to view the whole list. Initially you won't have any repositories listed; click the New Repository Location icon to add one. Once you've added a repository, drill down into it to find the project that you want to check out. Right-click and choose either Check Out (for a fast, no-frills checkout into your current workspace) or Find/Check Out As. Make sure you give the correct information for checkout: as with SVN generally, the repository is your top-level SVN repository (which may contain many projects), and your resource is the specific project you wish to check out.
There are a couple of wrinkles here if you're checking out an existing Java project. If the source code set up in the repository is an Eclipse project, including the .project file, you should be fine just to check it out into your workspace. If it doesn't exist as an Eclipse project, you need to use Find/Check Out As (or File -> Import...) to first create a project from SVN, then create it as a Java project using the New Project Wizard, in order to give it the correct properties. If you don't do this, Eclipse won't set it up correctly.
Once you have your project checked out, you'll find it much easier to work with SVN Kit if you show the SVN Toolbar. Go to Window -> Customize Perspective, then go to the Command Groups Availability tab and click SVN. The SVN toolbar buttons should then appear in your normal toolbar. Note that for these buttons to show up when you're editing your Java code, you'll need to customize the Java perspective, not the SVN Repository Browser perspective, though you may wish to do both.
Make a change to your code and click the Commit button (the red arrow into repository icon) to bring up the commit window. You'll be asked for a commit message, then challenged for user authentication data. Even if your repository doesn't need a password, you'll probably want to add a username to identify your commits. After you've entered this once, in the future it'll be assumed (you'll be prompted if your password has changed). If you want to change the username manually you can do so, but the process differs between SVNKit and JavaHL. You may be able to edit information via Preferences -> General -> Security -> Secure Storage, or alternatively you can delete the cached authentication file (with SVNKit this is .keyring or .eclipse_keyring in the Eclipse config directory).
Once you hit Commit, if there's a conflict, you'll get an "Unresolved Conflict" error message. If this happens, you must synchronize your local project version with the one in the main repository. Make sure you're in the Java perspective, then right-click on the project in the package explorer and choose Team -> Synchronize with Repository. You'll be prompted to open the Team Synchronizing perspective, which shows you the files that differ between your local copy and the repository in the left window. Double-click on a file to open it in the right window for comparison. Differences should be highlighted. Fix any conflicts here, resolve them, then commit your changes.
In the regular Package Explorer, right-click on a file or directory, then choose Team -> Show History to show its history in the panel at the bottom of the screen. Once you've shown a file's history once, you can return to the history later using the drop-down button on the History panel.
In theory, branching with Subversive is a straightforward operation. In practice, I found it initially tricky to get to grips with, but once I had a better handle on the model used, it did in fact work quite smoothly. Unfortunately, the online documentation is seriously lacking in detailed explanation of what happens when you click the Branch or Merge button.
For Subversive branching to work smoothly (and possibly to work at all, though my investigations were inconclusive on this point) you need to have your project set up with a trunk/branches/tags directory structure. After that, if you highlight the trunk in the Package Explorer and click Branch, you need to highlight the branches directory afterwards and click Update from Repository to actually see the branch directory. Once you've got that straight – particularly the repository layout (which is the default svn layout) – branching is a lovely one-click operation.
I also sometimes found it confusing to work out which file I was editing in the editor window – was it from the trunk, or one of the branches, and if so, which one? (You can mouse over the editor window title tab to find out.) Of course in most cases you won't be working in multiple branches at the same time.
Merging is a bit less straightforward; the merge dialog documentation isn't entirely helpful, and you need to make sure that you are clear on which branch you are merging into which. If you want to do complicated merges of different revisions, or to reintegrate two branches rather than merging them (i.e. to create one branch with a single history from them), Subversive's Merge dialog supports this, but I strongly recommend experimenting with a test repository before you skip blithely onward with your project's main repository. Alternatively, you can always merge from the command line then update from the repository. To be fair, the merge difficulties may be partly because Subversion itself arguably doesn't do a particularly good job of dealing with branching and merging (especially not if you're used to working with, say, Git, for which this is a real strength).
Strengths, weaknesses, and comparison with Subclipse
The fact that Subversive is an official Eclipse project and Subclipse is not is perhaps one argument in Subversive's favor. In general, however, both applications do the job they're intended to do. Subclipse's branching and merging support implements some best practice for you, but Subversive does so with a single click, which is great when it works. Both of them support the "check out as" option to check out code as an Eclipse Java project. Subversive also makes it easy to view diffs in the comparison view, whereas some people report finding this difficult with Subclipse.
Subversive uses several licenses (as it has connectors), whereas Subclipse requires no connectors, and runs under the Eclipse Public License, which may be helpful for certain business uses. The fact that you need to dynamically install connectors after installing Subversive may also be awkward for company users.
The Subversive documentation is fairly bad, and Googling for information tends to return a lot of results that just talk about Subversion (not Subversive) branching. While I haven't investigated Subclipse in depth, its documentation seems to be of higher quality, which may be enough of a factor to swing the difference.
In short, both utilities have advantages and disadvantages, and if you're about to make a general company decision, you'll probably want to try both. Either way, having that little bit of extra integration between your IDE and your version control should help make your life easier.
This work is licensed under a Creative Commons Attribution 3.0 Unported License