How to use Subversion with Eclipse

An anonymous reader writes "From the beginning, Eclipse included tight integration with the Concurrent Versions System (CVS) in order to provide access to change-management capabilities. Now, many projects -- notably those run by the Apache Software Foundation -- are using a different change-management system: Subversion. This article demonstrates how to add Subversion support to Eclipse and how to perform basic version-control activities from the IDE."

Comments

Eclipse 3.2 and Mac OS X/Linux

[Bob[Bob]]

Funnily enough I was setting this up yesterday... and I discovered for Eclipse 3.2 Tigris suggest using Subclipse 1.1.x as explained here. Also, for Mac OS X/Linux you need to first install JavaHL, as explained here.

It's all about changing focus. Modality.

[JonTurner]

>>I never understood why IDE integration with Source Control is so important.

IMO, the reason it's desirable is because a separate interface for source control changes your focus. I haven't seen any version control software that is really well integrated. Ideally, vcs (small-caps, version control software) should be invisible -- running in the background, checking out files as you need them, saving revisions with each change, maybe version stamping with each day/build/successful test pass/etc., and only intruding into the developer's thoughts when contention for a file exists. For example, if you're a solo developer you shouldn't even see the source control in day-to-day development. Only when you have an "uh, oh" moment and want to go back should you have to think about bringing up an interface or requesting an older file.

With multiple developers, the same thing. So long as nobody needs a file simultaneously for editing, vc stays out of the way. When two people need it, then the software starts asking questions.

Ideally, I'd like vcs to work like The Wayback Machine (archive.org) -- it's just there, always running, making archives in the background without any effort on the part of the web developer/administrator and nobody's the wiser. If you never need an old version, fine. But if you do, it's there for you.

Re:It's all about changing focus. Modality.

[DeafByBeheading]

Saving revisions with each change? You mean actually committing files as you save them? Maybe you're a way better coder than I am, but I often try a lot of things that have no business going into an actual revision history for a project. It seems that if you're committing code with each save (or even just each build for smaller projects), you're going to end up with a big mess in the history of your repository, wasting space *and* making it difficult to navigate. I don't believe invisible vcs could work well, at least not yet. Commits shouldn't happen on save or build or whatever, but when the developer feels, "Okay, this is a logically cohesive change to the code base". And what about commit comments?

Excellent article

[cerberusss]

I've been working with Subversion, especially from within Eclipse using the Subclipse plugin. I had earlier experience with the CVS plugin that comes with Eclipse. This is with Eclipse 3.1.1, Subclipse 3.0.1 and Subversion server version "SVN/1.1.4".

Some bad differences:

• Slow. While CVS isn't the fastest animal, I found some actions in Subversion even slower. And sometimes Subclipse just leaves you waiting up to tens of seconds when for example a conflict is detected. After posting on the excellent Subclipse mailing list, the problem was acknowledged. A few days later, a release was available through the Eclipse update screens which fixed this bug.
• When entering the Team Synchronize perspective, it happened once that although the "Incoming/Outgoing mode" was selected, only the incoming files were displayed. Switching to "Incoming Mode" and back again showed everything. Hmm -- smelly!
• Minor issue: when you have made a few changes and decide against it, you can right-click on the source and choose Replace With -> Latest from repository. Subclipse performs this, but Eclipse then asks something like "File changed on filesystem. Do you want to load the changed file into the editor?" Apparently, the integration isn't yet up-to-par.

Some differences I'm neutral about:

• In the Synchronization perspective, sometimes you review changes in a file and decide they should be left out. Funny thing is, you can't right-click and select 'override and update'. It's greyed out for whatever reason.
• When the repository contains a newer version, you often synchronize the file and choose 'override and commit' with the CVS plugin. With Subclipse, you synchronize, choose 'Mark as merged' and then commit.
• Whenever an error occurs (for example, you tried to commit a file which had conflicts), a little exclamation mark is displayed at the left side of the filename. You always need to right-click and choose 'Mark resolved' before you can continue.
• Directories are versioned as well. In the Synchronization perspective, you can't update a whole directory. Well, you can, but it doesn't disappear from the file list. You'll have to select the files as well as the directory.
• I was used to the CVS plugin. When I wanted to start working on a project that was kept in CVS, I used to do menu File -> New -> Project, then choose CVS > Checkout project from CVS. The Subclipse plugin doesn't put itself in the New Projects wizard. Instead, go to the SVN Repository Exploring perspective, seek out your project its directory, right-click on it and choose Check out. You'll then get the option Check out as a project using the New Project wizard.

Good things:

• You can just press 'Cancel' in whatever action -- Subclipse rolls back since Subversion uses transactions. With Eclipse's CVS plugin, this isn't possible (and with good reason or so I've heard).
• About Subversion in general: when you check in, you basically create a new revision. It's the collection of files that has a version, not each individual file. The complete commit has one commit comment -- not each file.
• About Subversion in general: symbolic links, permissions, everything's nicely stored.

Re:Why in the IDE?

[Chris Pimlott]

One, as another posted said, is for integration. If I just changed my files in the IDE, why should I have to go to another window to commit it? It's got integrated tools for exploring revision history, doing diffs, showing annotations, etc. It's handy.

Two, for refactorings. Modern IDEs have support for many common refactorings tasks, allowing you to (for example) pull out new sub-methods and be confident in the knowledge you haven't effected the rest of the program. Ideally, a version-control aware IDE can pass some of this information onto the repository, so when you rename a class, for example, you don't break the history chain.

Eclipse has robust support for version control schemes, and Subclipse (that's the Eclipse SVN plugin) is intelligent enough to correctly handle some refactorings, but not all. Still, they're working on it.

Re:Why in the IDE?

[Great_Jehovah]

The main advantage of integration with the IDE is that when you rename or move source files, it can automatically do the drudge work for you with svn. This is hugely important in Eclipse because all the fancy refactoring tools make the source tree much more plastic but it's all for naught if you have to go in after the fact and figure out which files got renamed to what manually.

Re:Subversion is not necessarily for Unix develope

[miniver]

But have you driven Subversion ... lately?

Subversion FAQ about Symbolic Links:

Does Subversion support symlinks?

Subversion 1.1 (and later) has the ability to put a symlink under version control, via the usual svn add command.

Details: the Subversion repository has no internal concept of a symlink. It stores a "versioned symlink" as an ordinary file with an 'svn:special' property attached. The svn client (on unix) sees the property and translates the file into a symlink in the working copy. Win32 has no symlinks, so a win32 client won't do any such translation: the object appears as a normal file.

You should also read up on Subversion External Definitions -- it looks as though you misunderstood how they really work.