Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×

How to use Subversion with Eclipse 84

Posted by timothy from the sneak-around-the-sun dept.
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."
This discussion has been archived. No new comments can be posted.

How to use Subversion with Eclipse More

How to use Subversion with Eclipse

Comments Filter:
  • I never understood why IDE integration with Source Control is so important. I think it is much easier to keep track of what you are changing if you explicitly go to the Source Control client and check in/check out exactly what you want. Am I missing something?
    • The 'I' stands for integrated. What's integrated about it if you need to go to a seperate program to do a routine action?
    • What I don't like is that IDE integration often means a project in the IDE = a project in source control. Worse, there might be a 1-to-1-to-1 with IDE project, source control project, and webapp.

      If this plugin can act as a good svn client, without being to tightly coupled to eclipse projects, then I'd be glad to use it.

      • You left out the part about the foil hat. SVN for eclipse doesent put any dependence on you using an eclipse project. In fact the plugin couldnt be more general purpose. I've used it for a year now.
        • You left out the part about the foil hat.

          Huh?
          I was asking a question based on previous experience, not slamming subeclipse.

          SVN for eclipse doesent put any dependence on you using an eclipse project. In fact the plugin couldnt be more general purpose. I've used it for a year now.

          Cool. That's the info I was looking for. I'll give it a shot and see if I like it better than smartsvn.
      • The problem is that most of the time some genius pants checked in the .project file and other configuration files that Eclipse uses. As long as you put .project (or better yet .*) in the ignore list, there shouldn't be any issues.
    • >>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 onl
      • 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.

        I have to strongly disagree with this. Changes should only be checked in when the developer decides they're ready, not every time you experimentally change some mundane detail. CVS

        • What you're wishing for sounds like the old VMS file system, where every file had a version number, and when you changed a file you just created a copy with the version number incremented. It worked OK...

          That was a scheme that I really liked (way back when), until the BOFH set a system-wide limit of three versions...

        • It all depends upon how you manage development. If you have a task that is going to require a significant ongoing effort (ie: more than a day or so) or that is going to require communication amongst multiple developers, or which will be undergoing lots of change (ie: you're doing research not development) then it makes sense to create a branch to manage the effort, and then merge the results of that effort back into the trunk when it's ready.

          Note: I'm not defending automatic check-in, I'm suggesting that

        • I also disagree with automatic checkins because of changes that affect several files. Even CVS doesn't get this right. You need atomic commits to ensure consistent states even in the case of major changes (like API changes, by example).
      • 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 wel
        • Having "grown up" on crazily unstable systems, I tend to save a lot; if my version control system stored a new revision for each save, I'd be up in the hundreds for a big/complex module before it even got to the "ready to compile" stage!

          Which would make version control unwieldly, unless you tagged every "real" check in.

      • VMS (Score:3, Interesting)

        by wandazulu ( 265281 )
        This is the *one* thing (really, only thing) that I like about VMS...every file is automatically versioned. I create a foo.c, it gets saved as foo.c;1. I edit it, save it, then there's a foo.c;2. I can always go back and look at foo.c;1 if I want and diff the two. What's also really slick is that you don't have to specify the version number ... it always assumes you want the current version, but if you do edit foo.c;1 again, and save it, then it becomes foo.c;3 (because there is already a foo.c;2).

        If any ot

        • Re:VMS (Score:1)

          by ebh ( 116526 ) *
          There is. It's called ISO-9660. It has native VMS-style version numbering right down to the semicolon. Course, that read-only thing might be tough to work around...

          More seriously, they're going to open the source to ClearCase's MVFS, which might be an interesting starting point. Depending on how it's implemented, you might be able to plug a different version control system into it.
      • 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.

        Hey, 1989 called. They want their version control paradigm back.

        (Sorry, couldn't resist.)
      • With Intellij Idea, this is how it works, with the caveat that the incremental, automatic checkins are done on a local version control system, and the developer decides when to commit to the actual vcs. Like pretty much everything else in Idea, it works great. You get superfine rollback control for even the smallest of changes. The only thing I'd change is to make the versioning persist across Idea restarts.

    • Re:Why in the IDE? (Score:3, Insightful)

      by hey! ( 33014 )
      The most important thing about source control is that people use it. Frequently.

      Since fixing integration problems with incompatible changes can play hell with your schedule, the wisest thing is to force yourself to do it every single day. If anything, source control isn't bound tightly enough with IDEs.
    • Well, the I in IDE stands for integrated. The main concept behind the IDE is to provide all of the necessary development tools in a single package (Code entry, syntax parsing, GUI design, etc.), and it would only make sense that the method of retrieving and submitting controlled-source code be included in such a utility.
    • 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

    • Re:Why in the IDE? (Score:5, Informative)

      by Great_Jehovah ( 3984 ) * on Thursday July 13, 2006 @12:15PM (#15713097)
      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.
      • Unfortunately though, you can't turn this off. There have been times when our users' directories get messed up because they forget to update and end up getting conflicts, and they can't "rename" or "copy" the real file they want to check in using eclipse, because it does svn stuff underneath (i.e. svn copy or svn rename). They have to go out to the filesystem to take care of that stuff, but they don't really understand that they can't do this in eclipse (they think, hey, it's my ide, why can't i do everyt
    • I guess the biggest reason for rolling version control into the IDE is convenience.

      I gave my developers a pretty easy-to-use setup for creating and using svn repositories, and taught them how to use tortoisesvn (this was ... probably svn 1.1 times). They never bothered, because they're IDE people (java devs, working mainly in eclipse), and the IDE sticks their projects and workspaces in inconvenient places.

      Then I taught them how to use subclipse about a month later, and now they generally find the reposito

    • I think it is much easier to keep track of what you are changing if you explicitly go to the Source Control client and check in/check out exactly what you want. Am I missing something?

      Yes, I think. While I don't routinely program much lately I have been testing some of Eclipse integration with CVS. It's very nice. Because Eclipse understand the source code structure it can do things like showing the difference in code structure, like which metods were modified compared to the remote version. It can show w

    • While I agree that the IDE should not be the only way to access version control (it's blasphemous, I know, but I don't use an IDE for everything), it is helpful to have access from the IDE when I am working it - no need to task-switch.

      The one thing that I find really helpful in the Eclipse integration with subversion is the display of diffs of Java source files. The diff is displayed in terms of language artifacts (such as showing that a particular method was added or modified), instead of simply simply

  • ... Wait till Eclipse happens, then attempt coup or other act of Subversion.

    This is particularly effective in places relying on visual recognition algorithms using only the visual spectrum in ambient light conditions.

    Unfortunately it might take several tried to get the timing right, and rebuilding a system just to have another go-around can be too time comsuming for most practitioners.

  • Eclipse 3.2 and Mac OS X/Linux (Score:4, Informative)

    by Bob[Bob] ( 60151 ) on Thursday July 13, 2006 @11:44AM (#15712891) Journal
    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 [tigris.org]. Also, for Mac OS X/Linux you need to first install JavaHL, as explained here [tigris.org].
    • IIRC if you install Subversion from Darwinports, it handles all the dependancies sanely; I can't remember if I had to specify the JavaHL stuff by hand, but I do remember that I installed that through Darwinports as well.
    • Don't use JavaHL if you don't want to,
      it's another dependency waiting to break.

      In the subclipse preference you can check the "Native Java SVN" support.
      It's not on by default, but has worked for my for several months.
      (I do eclipse/java development for work, I should know :-)

  • Excellent article (Score:5, Informative)

    by cerberusss ( 660701 ) on Thursday July 13, 2006 @11:49AM (#15712929) Journal

    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.

    • You may want to remove Subclipse and try Subversive [polarion.org]. It's free, and I've found it to be more reliable and full-featured than the Subclipse plugin. Check the FAQ before using for some info on migrating, if you choose to.

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

      That's a Subversion-ism - Subversion requires you do that via the command line whenever a file has conflicts, so Subclipse requires you do it via the GUI.

      Directories are versioned as well. In the Synchronization perspective, you can't update a whole directory. Well

    • Something that irks me still is that although subversion supports moving files, subclipse does not. One the command line, you can call a subversion command and move files and it retains the history. In eclipse, it will copy the file to the new location and delete the original. Thus the file history is lost.

      -br

      • Subclipse does support moving files in exactly the same way that Subversion handles moving files - copying the original (the history will remain attached) and then deleting the old copy.

        Check out the SVN manual and look up the "svn move" command. It says:

        This command is equivalent to an svn copy followed by svn delete.

        If you check the SVN console, you'll see it does indeed make the copy followed by the delete.

    • I tried using subclipse but it worked so slow and was so buggy it wasn't usable. Moving or renaming a file almost certainly broke the changelog.

      I switched back to IntelliJ which had a much more functional plugin. A few months later they added official support for SVN that was even better than the plugin. I don't regret the switch back at all. They even give free licenses to opensource projects.

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

      Actually, I think this is more something with eclipse or the plugin than subversion itself. The command line tools seem quite fa
  • Our developers transitioned to Subversion about 6 months ago, and since we almost all use Eclipse, we moved to Subclipse. We experienced lots of problems, particularly related to slow performance and branch-to-branch merges behaving strangely. Subsequently we moved to the Subversive plugin, which even in its beta state was more usable for us. Since then it is at RC stage and has proven very good in an environment with sometimes daily branching per developer. It feels much more like the CVS plugin than Subcl
  • Why is this under IT, and not under Developers?
    • I have another question for you. Why is it on Slashdot? Since when does /. post How To articles? With a mojority of /. users not wanting to be like Digg (blog spam, how to articles, more blog spam,...) I'm surprised to see it on /.
      • I'd rather see how-to articles like this then some of the other pie-in-the-sky, never happen, still waiting for terabyte optical drive articles.

        An post like this is valuable because I learned (through the comments) that there are 2 add-ins for Eclipse that support Subversion. Which is more information then I had yesterday. And I get a few opinions mixed in as to which of the 2 add-ins works better. I wish we'd see more discussions of what tools and techniques are in use.

        (It just so happens that we're
    • Why is this under IT, and not under Developers?
      Developers aren't the only IT folks who need (or are made to use) version control. Technical writers, graphic designers, sysadmins... You name it, those folks have a use for it.
    • Do not meedle in the affairs of IBM for they are subtle, and quick to anger.

      (That is, I have no idea how/why they choose to post things where they do.)
  • Right now, subclipse is buggy, unreliable and slow, particularly on large projects. I save a lot of time by using the command line svn client.
  • A bunch of us here, recently posed a question, which is currently intriguing me, regarding integration of eclipse with Visual Studio Team System (the ratio of .net to real-developers here is embarrassing).

    As much as I aim to avoid MS, it dominates my organisation, and unfortunately the rest of the world. An expensive commercial plug-in from Teamprise [teamprise.com] was available. So this got me looking around and I found that Visual Studio Team System Foundation Server exposed a soap service for interacting with its r

  • A buddy of mine has a nice howto on setting up subversion to tunnel everything over an SSH connection using private keys on Windows. Check it out.. http://marcchung.com/2006/03/11/ssh-remix/ [marcchung.com]

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close