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

84 comments

  1. Why in the IDE? by joekampf · · Score: 1

    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?

    --
    When a man lies he murders a part of the world.
    1. Re:Why in the IDE? by Daniel_Staal · · Score: 2, Insightful

      The 'I' stands for integrated. What's integrated about it if you need to go to a seperate program to do a routine action?

      --
      'Sensible' is a curse word.
    2. Re:Why in the IDE? by Anonymous Coward · · Score: 0

      I never understood why IDE's were so important. I think it's much easier to edit code in a text editor then manually invoke the compiler and linker.

    3. Re:Why in the IDE? by LDoggg_ · · Score: 1

      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.

      --

      "If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
    4. Re:Why in the IDE? by hey! · · Score: 2, Insightful

      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.

      --
      Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
    5. Re:Why in the IDE? by smbarbour · · Score: 1

      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.

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

    7. Re:Why in the IDE? by Chris+Pimlott · · Score: 2, Informative

      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.

    8. Re:Why in the IDE? by Anonymous Coward · · Score: 1, Funny

      No you don't.

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

    10. Re:Why in the IDE? by Anonymous Coward · · Score: 0

      There's a reason the UNIX philosophy is "small programs that do one thing, and do it well" - integrated programs are BAD. I'd rather have a separate text editor that does a very good job editting text and a separate compiler that does a very good job of compiling and a separate version control system that does a very good job of versioning than have all three bundled up into one mega-complicated application.

      IDEs fly in the face of that, and generally cause more problems than they're worth. Running "svn commit" or "svn update" via the command line isn't very challenging and is far less error-prone than hoping that the text-editor+compiler+debugger+version controller+whatever will do everything correctly.

      The UNIX philosophy is a good thing, and it's sad to see that people continuously decide to ignore it and bundle everything together into one giant overly complicated package.

    11. Re:Why in the IDE? by Anonymous Coward · · Score: 0

      separate

    12. Re:Why in the IDE? by M4N14C · · Score: 1

      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.

    13. Re:Why in the IDE? by Daniel_Staal · · Score: 3, Insightful

      That's an entirely seperate argument. If you are using an IDE, it makes sense that the IDE can handle all common coding tasks, one of which is source-control.

      Whether or not an IDE is a good idea is a seperate question all together. Maybe they are, maybe they aren't, maybe they only are for some people or situations. But if you are making one, it makes sense to make a good one.

      --
      'Sensible' is a curse word.
    14. Re:Why in the IDE? by Daniel_Staal · · Score: 1

      Sorry; I can't spell, and there is no spellcheck avalible for the browser I'm forced to use at work. (Moz 1.7 for OS/2.)

      --
      'Sensible' is a curse word.
    15. Re:Why in the IDE? by LDoggg_ · · Score: 1

      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.

      --

      "If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
    16. Re:Why in the IDE? by aftk2 · · Score: 1

      +1 Irony

      --
      concrete5: a cms made for marketing, but strong enough for geeks.
    17. Re:Why in the IDE? by aprilsound · · Score: 1

      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.

    18. Re:Why in the IDE? by ComputerizedYoga · · Score: 1

      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 repository to be indispensable.

      If you give them convenience, it won't be annoying to use, and they'll be more prone to using it. That's really the whole reason for that whole approach.

    19. Re:Why in the IDE? by scovetta · · Score: 1

      No, he really does. He works for me, and it takes him forever to rollback a change!

      --
      Wer mit Ungeheuern kämpft, mag zusehn, dass er nicht dabei zum Ungeheuer wird. --Nietzsche
    20. Re:Why in the IDE? by bit01 · · Score: 1

      You laugh, but just how much easier is it to click a button in a GUI or type a keyboard shortcut as compared to clicking up-arrow+Enter to re-invoke make on the command line?

      IDE's are productivity enhancers but they are often overrated. Programmers need to think more about what makes a development environment productive. Hand waving about buttons and "integration" doesn't cut it.

      ---

      Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

    21. Re:Why in the IDE? by aled · · Score: 1
      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 which files are modified in the project and you can configure it to show it in a different icon or font style.
      Also it doesn't lack anything in features to clients that I have seen, like WinCvs and TortoiseCVS. If it can do the same for Subversion, yet better.
      I understand that Netbeans have similar capabilities but haven't look into it yet.
      --

      "I think this line is mostly filler"
    22. Re:Why in the IDE? by Anonymous Coward · · Score: 0
      I wouldn't have that much of a problem with IDE's if they
      • didn't have a myriad of stuff that I don't need
      • had all the stuff I do need..


      Most text-editors can be configured to run 'make' with a keypress and that pretty much covers the special IDE'isms that I use. Although.. context-help would be nice but many of the IDEs tend to be quite language+library+compiler specific in that making it next to useless.
    23. Re:Why in the IDE? by the+hermit · · Score: 1

      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 everything in here!); eclipse makes it too transparent that it's doing svn stuff underneath.

    24. Re:Why in the IDE? by Anonymous Coward · · Score: 0

      separate

    25. Re:Why in the IDE? by aevans · · Score: 1

      It's true. IDEs were created when you didn't have a gui that could handle multiple xterms. Considering build/deployment often includes two or more sets of environment variables, sometimes on multiple systems, editing several files simultaneously, running unit tests, etc. a multi-window environment is handy. It was netbeans (accidentally) that helped me realize that an IDE is just a bunch of windows stuck together. And a modern desktop metaphor graphical shell can do all that except the sticking together / resize hell. Give me ALT+TAB and virtual desktops over resizable frames and multiple "perspectives" any day -- except Sunday.

    26. Re:Why in the IDE? by rfreedman · · Score: 1

      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 as a textual diff. I've been wanting to see something like this for years, and the implementation (not sure if it is part of Eclipse's 'team' environment, or the plug-in) is as good as I could possibly hope for.

  2. Thats Easy! ... by powerlord · · Score: 2, Funny

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

    --
    This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
  3. I'll stick with eclipse, thanks. by Anonymous Coward · · Score: 0

    Why is it everytime there's an eclipse posting on slashdot, someone tries to sell us IDEA? Rather spammish don't you think?
    It might very well be a decent dev environment, but if you want to use it commrecially it's 500 bucks.

    Eclipse is also more than just java. Apples and oranges, man.

    1. Re:I'll stick with eclipse, thanks. by bunions · · Score: 1

      For the same reason that whenever there's a post about windows, everyone crowds in to sell people on linux - because it's better. Of course, if you do work in languages that aren't primarily Java/Javascript, then it's not for you. But if most of your time is spent in Javaland - my condolances ;) - then Idea is a far superior IDE, and well-worth the money if you're doing it for a living. And if you're broke, there's the EAP, where you get to use the latest stable beta for free.

      A friend of mine used to contend that Eclipse should simply use percent of Idea features implemented as their version number, which I found amusingly malicious and sort of true.

      --
      there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
    2. Re:I'll stick with eclipse, thanks. by Anonymous Coward · · Score: 0

      You preach IDEA and still confuse Java and JS..?

    3. Re:I'll stick with eclipse, thanks. by bunions · · Score: 1

      No. Idea is also a fairly awesome Javascript editor.

      --
      there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
  4. 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.

    1. Re:Eclipse 3.2 and Mac OS X/Linux by Anonymous Coward · · Score: 0

      When will it support "git"?

    2. Re:Eclipse 3.2 and Mac OS X/Linux by chrish · · Score: 1

      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.

      --
      - chrish
    3. Re:Eclipse 3.2 and Mac OS X/Linux by pAnkRat · · Score: 1

      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 :-)

      --
      we need an "-1 Plain wrong" moderation option!
  5. It's all about changing focus. Modality. by JonTurner · · Score: 2, Informative

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

    1. Re:It's all about changing focus. Modality. by 14erCleaner · · Score: 2, Insightful
      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 is great for this purpose, as it allows disposable copies to be checked out without having to lock out others all the time.

      Automatic checkin would be a disaster in any project with a lot of developers sharing source code. If the incompetent asshat in the next cubicle accidentally deletes a file, do you want your builds to immediately start failing? Didn't think so.

      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 and kept people from making irrevocable screwups in many cases, but it wasn't an effective version control system. In particular, there were no revision comments and no binding of revisions to bug reports, features that are important in modern vcs systems, especially for large projects.

      --
      Have you read my blog lately?
    2. Re:It's all about changing focus. Modality. by DeafByBeheading · · Score: 2, Informative

      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?

      --
      Telltale Games: Bone, Sam and Max
    3. Re:It's all about changing focus. Modality. by timelorde · · Score: 1

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

    4. Re:It's all about changing focus. Modality. by miniver · · Score: 1

      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 there are ways to manage development beyond single branch development, without requiring that every change to the system have its own private branch.

      --
      We call it art because we have names for the things we understand.
    5. Re:It's all about changing focus. Modality. by mypalmike · · Score: 1

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

      --
      There are 0x40000000 types of people: those who understand 32-bit IEEE 754 floating point, and those who don't.
    6. Re:It's all about changing focus. Modality. by madth3 · · Score: 1

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

    7. Re:It's all about changing focus. Modality. by chrish · · Score: 1

      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.

      --
      - chrish
  6. 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?
    1. Re:Excellent article by Scaba · · Score: 1

      You may want to remove Subclipse and try Subversive. 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.

    2. Re:Excellent article by _xeno_ · · Score: 1
      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, you can, but it doesn't disappear from the file list. You'll have to select the files as well as the directory.

      I've noticed that the Team Synchronization window appears to be flat-out buggy under Subclipse - buggy enough that I essentially never use it. If you want to update an entire folder, it's easier just to update it in the Package Explorer/Navigator and forget about the Team Synchronization perspective. Directories being versioned is generally a good thing (it means that they can also be deleted and copied within the repository). However I've had Subclipse cause weird problems when moving directories via Eclipse.

      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.

      That's been fixed in the latest versions of Subclipse, at least under Eclipse 3.2. You can now check things out via SVN in the New Project Wizard.

      --
      You are in a maze of twisty little relative jumps, all alike.
    3. Re:Excellent article by blurryrunner · · Score: 1

      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

    4. Re:Excellent article by _xeno_ · · Score: 1

      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.

      --
      You are in a maze of twisty little relative jumps, all alike.
    5. Re:Excellent article by size1one · · Score: 1
      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.

    6. Re:Excellent article by xenocide2 · · Score: 1

      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 fast, but even with the latest updates, the damn thing's slow. It also chews through a ton of objects, so much so that I sometimes encounter thrashing. But a far more important bug in my view is that apparently drag and dropping directories in your project may not be reflected appropriately in SVN, resulting in your commit being screwy and updating pulling back in the directory you wanted moved.

      Definitely, subclipse isn't as fully integrated as CVS is. Hopefully it will be able to catch up soon and make the nessecary improvements.

      --
      I Browse at +4 Flamebait

      Open Source Sysadmin

  7. Subversion by Anonymous Coward · · Score: 0

    What's it all about?

    Is it good, or is it whack?

  8. Re:Subversion is not necessarily for Unix develope by Just+Some+Guy · · Score: 3, Insightful
    For Unix I'd rather stick with CVS since SVN does not support following symbolic links because Windows(!) does not support symbolic links.

    But it does support versioning the symlink itself (per the FAQ). Do you really want to store multiple copies of the symlink's source?

    --
    Dewey, what part of this looks like authorities should be involved?
  9. Re:Subversion is not necessarily for Unix develope by miniver · · Score: 2, Informative
    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.

    --
    We call it art because we have names for the things we understand.
  10. VMS by wandazulu · · Score: 2, Interesting

    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 other operating system (preferably a Unix-based one)'s filesystem implemented this, I'd be in hog heaven. Reiser is supposed to have the concept of plugins, and I even took a look at the docs, but fs hacking is way out of my league.

    You don't get *true* version control, of course...comments, checkouts, properties, etc., but just knowing that you can have an uh-oh moment and go back one or two versions is a real life saver.

    1. Re:VMS by plague3106 · · Score: 0, Troll

      It seems to me that Ctrl-Z fulfils this need rather well for me.

    2. Re:VMS by ebh · · Score: 1

      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.

  11. Re:Uh, thanks... by Profane+MuthaFucka · · Score: 1

    Great! Can't wait to get coding in Python and C++ with this excellent IDEA IDE.

    Oh, wait. Java only? Nevermind, I'll stick with Eclipse.

    --
    Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
  12. Subversive? by Anonymous Coward · · Score: 0

    What about the Subversive plugin?
    It was basically developed as a better alternative to Subclipse, in the same way that Subversion was made as a better alternative to CVS.
    I've been using Subversive for the past few months, and for me, it works much better than Subclipse, though YMMV.

  13. Subversion Sucks. by Anonymous Coward · · Score: 0
    1. Re:Subversion Sucks. by Taevin · · Score: 3, Insightful
      Right, because taking the opinion of clueless idiots is always a good idea.

      He said he read the entire manual and still couldn't figure out the most basic of SVN operations? His reading comprehension skills must be so handicapped that I find it difficult to believe he managed to get a wordpress blog running. I downloaded, compiled, and installed subversion without reading the manual and then skimmed over the documentation to get it running.
      The error: permission denied on db/transactions/1-1.txn. And I can't figure out what it means. What permissions? Who's trying to access that? Why is it necessary? Why doesn't my user have those permissions when I attributed everything correctly?
      Can't figure out what it means? WTF? Either this guy is from Windows where you don't deal with permissions because you're always an administrator or he has absolutely no business setting up a server of any kind. I got that same error the first time I setup subversion through the Apache module. I immediately said "Oops, forgot to give the apache user write access to that directory, duh." So sorry that every program doesn't have a 2,000 page section in its manual covering the basics of its host operating system.

      I've never used either of those repository management programs he speaks of since they are completely unnecessary given how easy it is to manage an FSFS based Subversion repository, but I'm going to go out on a limb here and say they'll work perfectly for every other user.

      Creating a Subversion repository is an incredibly simple task. The svnadmin utility, provided with Subversion, has a subcommand for doing just that. To create a new repository, just run: $ svnadmin create /path/to/repos
      No, it's not that simple, and no it's not 'just run'. Where should the repositories reside? What are some normal defaults for this sort of situation? What do the authors recommend? What should the permissions of the repository paths be? What should the permissions of the repository root folder be? It's never 'just run'.
      Actually it is that simple. That command has never failed to create a repository when I used it, and it was a simple matter of double checking the permissions afterwards and are of course easily fixed with a recursive chmod. What are some normal defaults? What do the authors recommend? I thought you read the manual asshole: The shockingly labeled "Choosing a Repository Layout" section. What should the permissions be? Umm, maybe the most restrictive ones necessary for operation, like they are or should be for every program in existence. If you're running it through the Apache module and want to commit changes and therefore write to the filesystem, perhaps the user Apache runs as needs, oh I don't know, write permissions.

      Subversion has worked flawlessly and exactly according to the published documentation in every single instance I have used it. The only problems that have ever occurred in relation to it were of my own mistakes (not giving the apache user access, etc.). Given that I find it very hard to believe that someone able to comprehend a revision control system could fail so completely at such a simple task, I find it more likely that this asshole just hates Subversion because it's different and is/becoming more popular than his system of choice.

      At least I'll know not to believe a single word from Sebastien Reid if I'm ever linked to his "tech blog" again.
    2. Re:Subversion Sucks. by Lord+Bitman · · Score: 1

      afaik Subversion needs rw permissions even for "read-only" operations.

      --
      -- 'The' Lord and Master Bitman On High, Master Of All
    3. Re:Subversion Sucks. by Anonymous Coward · · Score: 0

      that was one of the best posts ever. thank you for saying exactly what i was thinking.

    4. Re:Subversion Sucks. by Taevin · · Score: 1

      That might be true, I don't know to be honest because I always give rw permissions anyway since I like to check my code in ;) As far as I remember though, the time I screwed that up I was able to check-out my project (a read-only operation) fine - it was when I tried to commit my changes that it threw the permission denied error.

    5. Re:Subversion Sucks. by mabinogi · · Score: 1

      Only if you use the BDB backend. if you use FSFS then it doesn't.

      --
      Advanced users are users too!
    6. Re:Subversion Sucks. by chrish · · Score: 1

      Actually, he's got a point about Subversion's error messages; they're pretty bad for the "end users"... devs don't care what the server is up to, or how perms are set there, etc. they just want things working. Having a sensible error message that told them "this is probably a server config problem" vs. "your sandbox is hosed, you might want to revert or something" would be really helpful.

      Error/exception reporting is a bit of an Achilles heel for software in general though, not just OSS development tools. ;-)

      --
      - chrish
  14. Idea implements this in a smart way by bunions · · Score: 1

    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.

    --
    there is no need to sign your posts. this isn't usenet. your username is right there above your post. stop it.
  15. Subversive is even better! by The+Code+Hog · · Score: 1

    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 Subclipse does though that is obviously a subjective thing.

    It is open source, has frequent updates, and retains a lean feel. Check it out: http://www.polarion.org/index.php?page=overview&pr oject=subversive

    --
    -- "Vote Democrat. Because the current crop of conservatives are just bugnut crazy."
    1. Re:Subversive is even better! by mikeburke · · Score: 1

      +1 for subversive

      Another important point - Polarion (the authors) recently submitted a proposal to make subversive a standard project under eclipse.org

      http://www.eclipse.org/proposals/subversive/

  16. Why... by RoloDMonkey · · Score: 1

    Why is this under IT, and not under Developers?

    --
    Long live the Speaker Bracelet
    Rolo D. Monkey
    1. Re:Why... by jokerr · · Score: 1

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

    2. Re:Why... by ShaunC · · Score: 1
      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.
      --
      Thanks to the War on Drugs, it's easier to buy meth than it is to buy cold medicine!
    3. Re:Why... by WuphonsReach · · Score: 1

      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 getting ready to start using Eclipse and Subversion. So the article is especially timely.)

      --
      Wolde you bothe eate your cake, and have your cake?
    4. Re:Why... by chrish · · Score: 1

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

      --
      - chrish
  17. subclipse still has some way to go by 0xbeefcake · · Score: 1

    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.

  18. Not 500 bucks if you time it right. by Deef · · Score: 1

    If you buy between (usually) December and January, they offer it as a SUBSTANTIAL discount to individual users. Usually around $250 or less. This is called a "Personal" subscription or somesuch.

    Personally, I think it's well worth the money. I've tried Eclipse, and Idea seems a lot more streamlined and less awkward.

  19. [OT] Interfacing VSTS From Eclipse and beyond by ACORN_USER · · Score: 1
    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 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 repository. So this reminded me of an old Dr. Dobbs article which led me back to the VSTSEclipse project on sourceforge.

    The project hasn't released any source yet, however looking at other mailing lists it appeared that there had been some activity in the past. I have a feeling that Teamprise actually bought up the VSTSEclipse team, given that I saw a post where a VSTSEclipse developer claimed to have started working for them. So that leaves you with the question as to who else is doing this. Which leads you to thinking that 'I'd like to write an open sourced intermediary service which communicates with VSTS Foundation Server and exposes a familiar and open interface to the rest of the world; including an Eclipse Plug-in.

    Does this exist yet? Anyone else interested?

  20. Re:Subversion is not necessarily for Unix develope by the+hermit · · Score: 1

    Last time I checked though, eclipse didn't like symlinks with svn on a mac. It totally hangs when doing anything with a project that has one.

  21. Transitioned? by alienmole · · Score: 1
    Our developers transitioned to Subversion about 6 months ago

    Transitioned? Sounds like you've contracted a pretty severe case of management-speak. Been leveraging one too many paradigm-shifting synergies, perhaps? The word you're looking for is "switched". As an antidote, I recommend playing Bullshit Bingo at your next meeting.

    But thanks for the link to Subversive! :)

  22. SVN SSH Tunneling Information by ConMotto · · Score: 1

    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/