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."
... 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.
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.
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.
>>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.
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.
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:
Some differences I'm neutral about:
Good things:
8 of 13 people found this answer helpful. Did you?
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.
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.
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?
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.
Subversion FAQ about Symbolic Links:
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.
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.
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.
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. 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.
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.