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

Re:Why in the IDE?

[Daniel_Staal]

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

Re:Why in the IDE?

[hey!]

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.

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

[14erCleaner]

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.

Re:Subversion is not necessarily for Unix develope

[Just Some Guy]

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?

Re:Why in the IDE?

[Daniel_Staal]

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.

Re:Subversion Sucks.

[Taevin]

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 [red-bean.com]. 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.