To my knowledge, there are two free Eclipse plugins to use Subversion as a team provider: Subclipse and Subversive. I started out with Subclipse, but after Eclipse started crashing a lot when I moved from coding to team tasks, I pulled down Subversive to give it a whirl, hoping it would address the crashes. Which one did I just finish uninstalling, you ask? Read on.
First off, using Subversive didn't resolve the crashing, so it's either the team framework code, or something else (I've a suspicion debug-mode Tomcat instance I've always got running).
By and large, the two plugins were very similar. Minor differences included slightly different ordering of options on the context menu and different icons/labels. A large percentage of the UI, however, is driven by the core team framework, not the individual plugins.
Some of the more significant differences included the ability to create working copy change sets with Subversive, but not Subclipse. That can be quite handy if you're stuck working on two (or more) different things in the same working copy at the same time. Subversive also had a bit more intelligent repository browsing, automatically detecting the "standard by convention" trunk/tags/branches top-level directories and letting you browse them for what they are, rather than just generic directories. For a lot of operations, Subversive seemed noticably faster, but on occasion it would take forever to do the simplest things (like commit a single small file). Finally, Subversive's various dialogs exposed a rather richer feature set, though the vast majority of it is useless to me.
Subclipse, on the other hand, had very consistent performance. It also was much faster to "spin up" when loading a project for the first time and building all it's internal metadata for label decorations and stuff. It also seemed slightly faster on synchronize operations. One rather significant advantage for Subclipse was the merge viewer. While it's not for the faint of heart, it's quite powerful, and on the couple merges I did with Subversive, I felt slighted. One little edge case that I did find, Subclipse will let you connect over SSL to a repository whose SSL cert requires manual confirmation to accept (expired, non-trusted issuer, etc.), while Subversive just said it couldn't connect to the repository without attempting to get that confirmation. Not a huge deal, but I run my repos on a self-signed SSL cert, so I couldn't connect to them with Subversive unless something else (like Subclipse) had already done the confirmation.
So which one did I keep? Subclipse. Subversive's definitely got the potential to scoot by Subclipse in terms of feature set and usability (and will get a big boost if it becomes and official Eclipse project), but at the moment, Subclipse isn't lacking a bit. To be fair, Subversive has targetted a larger feature set and is a younger product, but I'm not considering developer merit, only how well it fits my needs. I know I'll be revisiting this question again next year sometime, and I'm not confident predicting either way.
What version of Subclipse are you using? Subversive only added the changeset feature in response to Subclipse having it, so I was curious to see you think that Subclipse does not have it. The feature is identical since most of the UI comes from the Synch view, so you could not have just missed it in Subclipse.
I tend to think you were using the latest version of Subclipse because you mentioned performance, and there have been major performance improvements in the last several releases. I just do not know why you would not have found the changeset feature.
If you are using the older 1.0.3 version (which does not have changesets) then you are in for some pleasant surprises on performance.
The current version is 1.1.8.
I tried Subversive as well but then read an insightful post by one of the Subversion developers …
http://eclipsezone.com/eclipse/forums/t77149.rhtml
Scroll down to entry #10 I think…
After reading that I switched back to Subclipse…
Jim
Mark,
Sure enough, I am in fact using 1.0.3. Thanks for pointing that out. Doing the 1.1.8 update as we speak, and from what you say, it sounds like I'll be even happier.
There should be a significant performance boost throughout the tool. Also, it includes SVN 1.4 which has a new WC format that is smaller and has less files and also improves performance. SVN will silently update your WC on first touch. This process might make something take longer than it would have before, but once that is done everything should be a lot faster.
Besides performance, there are a lot of UI improvements. My favorite feature is probably the new Team -> Show Annotate option that uses Quick Diff to markup the editor with annotate info.
Mark
For some reason this post popped back up on my Bloglines subscription. Anyway, it inspired me to check in and see how you are doing? Did 1.1.8 bring further performance and usability improvements for you?
Fingers crossed.
Mark
I'd been hosting my blog on a old laptop in our company's rack for free. But then it died, so I switched to a shared host. The entries all have new GUIDs with the new system, so they show up as new in feed readers. Cest la vie.
1.1.8 doesn't seem noticibly faster, and it's got this weird habit of indicating lots of phantom directory updates in the Synchronize view. Not sure what's up with that. Just have to do a no-op update to get rid of them, but it's like the working directory can't deal with directory revisions older than the directory's content's revisions all of a sudden, but can't resolve it automatically. I've also really noticed the lack of being able to cancel the commit dialog and then next time you open it have the message you had been typing still there. Subversive did that, and didn't notice how nice it was until it disappeared.
The message you were typing should be in the drop-down list of previous messages — should be the first one.
The "phantom folders" is a new, relatively important, feature. Whenever you do a commit, the folders in your local WC become "out of date". This can cause unexpected problems later if you do an operation that requires the folders to be up to date before you can commit the change, such as a rename. So we know show the out of date folders in the view so that they can be updated. If you really do not like this, and do not think you need it, you can turn it off via the "Show Out of Date Folders" preference which is also a toggle right on the view's drop-down menu. I'd suggest keeping it on.
Subversive has this same feature, they just have it off by default.
Sure enough. Thanks for pointing that out. It used to do that a long while ago, and then it stopped, and I'd never bothered to check again. At least for my workflow, it seems like having a cancelled message just showing up as the default would be nicer, because usually when I cancel a message it's because I need to go look at something in the code (like a line number) and then go right back to doing the same commit.
Regarding the out of date folders, that makes sense now. Any reason they show up as duplicates in the sync view (i.e. a folder that is out of date which also contains local changes will actually be shown twice)? That just a limitation of the core Eclipse sync sutff?
The showing up twice is an Eclipse bug that should be fixed in 3.2.1.
Still, I don't get why not to turn 'Show out of date folders' off. Certainly, there's much more people embarrassed with this feature, than who enjoy it.
MegaS,
As Mark said, you can turn it off if you want. But after having it around for a while, my annoyance has waned significantly. It'd be nice if the folder update would happen automatically if it's a no-op, but it's still good to know that you have to update.
To barneyb:
In my opinion, it should be off by default. If you are an experienced user of Subclipse, you can turn it on.
Let's say, we have 2 situations:
1) ('Show out of date' is on) newbie installs subclipse, commits first time – than go to google or ask somebody – is this a bug?
2) ('Show out of date' is on) newbie installs subclipse, use it for some time, everything is ok – and after that he maybe run to a problem, and maybe not. Maybe he'll never know he have to update folders after each commit, and so, he's life we'll be easier & happier:)
As projects mature, I'm quite sure that this nearly 2 yrs old post may be a bit outdated about the set of stability and features. However, you were on top of the Google's search results.
Amir,
I haven't done another in-depth comparison, but I still use Subclipse every day without any issue. I've gone and looked at the Subversive site a couple times, and while they did attain their goal of being incubated into the Eclipse project infrastructure, it doesn't look like much has changed with the code.
So yeah, it's two years old, but I don't think it's nearly as invalid as you'd expect for a software comparison of that age.
Very, very valuable – you just saved me hours. I will stick with Subclipse. One caveat emptor re Subclipse: as of 1.3, it forces you to use SVN 1.5, which as of this posting I think is still beta.
Noah,
I haven't tried the 1.4 branch of Subclipse, but the site says it requires version 1.5 of SVNKit/JavaHL. So I would expect it to work fine against Subversion 1.4 repositories. To put that another way, it's only the client that needs upgrading, which Subclipse should take care of automatically.
It definitely works against all repositories, that is true. However I work with both the command-line and the IDE, and now when I try to use the SVN 1.4 client at the command line with code I checked out using Subclipse, I get this message:
"svn: This client is too old to work with working copy '.'; please get a newer Subversion client"
So much for SVN backward compatibility, eh? Unless I am doing something wrong here – would love to know if that's the case.
Noah,
Yes, that's true. Subversion has only promised backwards compatibility on the server. They've always reserved the right to make non-backwards compatible changes with the working copy metadata on changes to the 'y' in 'x.y.z' releases. The 1.4 release had a similar working copy change that required an upgrade, and I'd expect that to be the same moving forward.
Thanks for the info on that. And once again, thanks for the valuable article.
I tried subversive but switched back to subclipse because of a single issue which happened to make subversive impossible to use for me.
svn has this feature where it shows "all changed paths" of a checkin. You can turn off the view that displays this in the history view. When off, subclipse does not retrieve this information. The bug in subversive is that it does retrieve this information regardless. In our case, the entire source was checked into the repository in rev 9. The change set therefore includes all paths in our repository, about 30MB worth of data if pasted into a text file. So subversive would go and download 30MB worth of data every time I wanted to look at the history of a file, and it affected all files since they are all part of the first change set. That made subversive unusable for me.
The one feature I am missing from both is a "move change to branch" command which quickly and easily can move a change in trunk to a path. The equivalent of svn merge, but with automatic tag/branch detection and automatically filling in the correct parameters. I often work in /trunk, then we decide a fix/feature needs to go in the current release branch… automating this would be awesome.
Thanks for the review… I too was curious about switching over. I do wish Subclipse had the functionality that TortoiseSVN does… it especially struggles with deleting files and I've had quite a few times when it's managed to eat itself.
I'm using newset Subversive and I haven't any problems with this.
sNop,
You haven't had any problems with what?
Neither really. But I havn't used branching/taging yet, but I'm using this features very often, so when I will have any practice about branching/taging then I post here my point of view.
Ony one thing which I lack is, that in compare dialog(from commit dialog) havn't maximize button.
I've been working with Subeclipse for the last few weeks and we do a LOT of branching and switching (we use a full branch for every modification) and I must say that for anything beyond commits, I use Tortoise. Subeclipse does weird stuff or crashes on any kind of branch op… I could document the behavior but I'm usually too busy deleting my entire build, putting a new one back in place, and doing an update from SVN.
TortoiseSVN is one of a handful of apps that keep me using Windows (for now), although soon it will be relegated to a VirtualBox.
Daniel,
I can't say I've shared your experience with Subclipse or Subversive. Switching sometimes takes a while (most of our working copies are in the 400MB range), but I've never had it crash out. In any case, you should be able to issue a Cleanup command, and then reswitch and pick up where you left off.
Hi Barney, thanks for your comment. I'll keep testing and post here again if I see the light with Subeclipse, or if I have more details on the problems that I've been having.
Off topic/@Daniel Rosenstark: Idunno if it's still interesting, but you were mentioning TortoiseSVN in your post two years ago. In the meantime kdesvn has come a long way, enough so that I don't feel any loss now that I switched to Kubuntu and have no TortoiseSVN anymore.
@Me, myself and I: I am GIT-only now and it's great, even with no good GUIs to speak of. But I'm always glad to hear that the *nix's are keeping up.