– also known as – is a source version control system created by CollabNet Inc. and currently part of Apache Software Fundation. Today is preferred to CVS since it supports many advanced features, like atomic commits (either all the changes – even spanning multiple files – are registered or the state of the repository is unchanged), tracking of copy/rename/delete operations (the history of a file is no longer lost when it’s copied or renamed) and support for “properties” (arbitrary metadata that can be attached to the files).

SVN is widely deployed and there are many tools to manipulate the repository; using a SVN repository from Eclipse IDE it’s pretty simple since the available plugins provide a seamless integration with the editors and the standard workflow.

In order to interact with a SVN repository from Eclipse itself we need an appropriate team connector; a few alternatives are available, the most popular being  Subversive (that will be used in this ) and Subclipse. The plugins are tuned for Java development, but can be used with any kind of Eclipse project.

Eclipse has its own interface for installing the plugins, via the Help -> Install new software menu.  After entering the URL of the plugin update site (currently http://download.eclipse.org//subversive/0.7/update-site/, but see Subversive site for the latest release), the wizard shows the available plugins.

For a typical Java setup the items needed are the Team Provider – which is the main component providing the core functionalities – and the JDT Ignore Extension – which automatically excludes the compiled Java files from the commits; the latter is not strictly needed but it’s very handy when dealing with Eclipse Java project. In the integration Subversive Integration there’s a plugin for integrating with Mylyn, making SVN views aware of the Mylyn context in use.

At the first use Subversive will ask to install the last missing piece: the provider, i.e. the software component that allows the abstract interface (the Team Provider) to talk to the SVN server. Typically two choices are available: JavaHL is a Java wrapper for the native SVN libraries; this provider is feature complete and very fast but the installation wizard only provides win32 binaries – with other platforms the required libraries must be installed separately (e.g. libsvn-java for Debian and derivates). SVNKit is a pure Java library that can be used instead of JavaHL; it lacks some advanced – albeit rarely used – functionalities (like direct file access to the repository, SSPI authentication) and it’s somewhat slowever with large repositories but it’s entirely self contained and installing it on any supported platform requires just one click with Subversive wizard.

The newly installed plugin provides a new perspective (SVN Repository Explorer) and adds some features to the Resource view. The repository explorer perspective is the main entry point for a typical SVN workflow: here the user can browser existing repositories, add new ones and checkout the sources to start working. SVN repositories can be access using different transports: the native protocol (denoted by the svn:// URI scheme) which is fastest and the simplest to setup server side; http or https encapsulation via DAV which offers the greatest flexibility (especially in terms of authentication mechanisms); SSH tunnelling (svn+ssh:// scheme) which is basically the native protocol over a SSH tunnel.

In order to add a new repository to Eclipse the user must provide the URL of the repository itself and (optionally) his or her credentials; some public repositories might allow anonymous read-only access, but for write (commit) access the authentication data is typically required. It’s possible to change more advanced settings like the location of the proxy server (when using HTTP or HTTPS), SSH parameters (when SSH tunneling is used) and the SSL certificate for client authentication.

The standard layout of a SVN projects spans three directories: trunk with the main development line, branches for the branches and tags for hosting the tags. From the explorer it’s possible to checkout the sources into the current workspace: the first option is the simple Check Out which checks out the sources into the workspace as a new project; if the repository already contains an Eclipse project the it’s recognized automatically, otherwise the default generic project is used. The second option is Check Out As… which offers more flexibility during the checkout; in the wizard is possible to checkout the data into an existing project (or in a sub directory) or to create a new project from scratch and populating it with the data from the repository.

When a project is linked to a SVN repository its items (source files and other resources) are decorated with a small symbol in the lower right corned of the icons; furthermore for items that already under version control the revision of the resource is displayed next to its name (the appearance can be customized). Items that are tracked by SVN and unmodified in the working copy are tagged with a small repository symbol (Main.java); modified items uses the same symbol by the name is prefixed by “>” (MyClass.java). Items that have been added to SVN but are not yet committed are marked with a small clock icon (AnotherClass.java) while items that are not known to the version control (i.e. newly added files) are tagged with a small question mark (YetAnotherClass.java). SVN commands are available through the “Team” sub-menu on the contextual menu; from here it’s possible to operate on one ore more files while staying the current perspective. Sometimes – however – it might be useful to have a global global view of the status of the project (especially when merging incoming changes);  the “Synchronize with Repository” in the “Team” sub-menu does precisely this:

In the example it’s possible to see that there are both outgoing changes (AnotherClass.java), incoming changes (Main.java) and even a conflict (MyClass.java). In the synchronization view, double-clicking on a resource opens the comparison view where the user can see what has been modified in the working copy and what is changed on the repository. The comparison view can be used for inspecting incoming changes before an update or outgoing modifications before performing a commit; the same view is also used for manual resolution of the conflicts.

The comparison view shows side by side the content of the file in the working copy and the content of the same file on the repository. This view – when used on Java source files – also gives a structural overview of the modifications. In the example it’s possible to see that there’s an incoming (non conflicting) change on method say() of HelperClass, while there’s a conflict in the method hello() of MyClass. The source comparison instead show the details of what is changed inside the file; in the source view the user can selectively apply incoming changes (e.g. the second modification in the example) and manually fix up any conflict. Using the toolbar of the source compare view it’s also possible to let the tool pull in all non conflicting changes from the remote copy, leaving only the conflicts to resolve; while this function might come in handy it should be used in conjunction with a manual review of the file, since the tool only ensures that the merged bits are non-conflicting, not that the end result is actually semantically correct.

A complete reference manual of Subversive is available at http://www.eclipse.org/subversive/documentation/index.php