Slashdot Mirror


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."

4 of 84 comments (clear)

  1. Eclipse 3.2 and Mac OS X/Linux by Bob[Bob] · · Score: 4, Informative

    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.

  2. Excellent article by cerberusss · · Score: 5, Informative

    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.
    --
    8 of 13 people found this answer helpful. Did you?
  3. Re:Why in the IDE? by hhlost · · Score: 5, Funny

    I think it's much easier to edit code in a text editor then manually invoke the compiler and linker.

    Personally, I think it's much easier to use pen and paper, an abacus and a filing cabinet.

  4. Re:Why in the IDE? by Great_Jehovah · · Score: 4, Informative

    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.