Comments on: Subclipse vs. Subversive

By: barneyb

barneyb — Fri, 21 Nov 2008 17:37:45 +0000

sNop,

You haven't had any problems with what?

By: sNop

sNop — Fri, 21 Nov 2008 13:26:06 +0000

I'm using newset Subversive and I haven't any problems with this.

By: Jevon

Jevon — Mon, 18 Aug 2008 01:39:25 +0000

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.

By: Nikolaus Heger

Nikolaus Heger — Fri, 15 Aug 2008 03:08:57 +0000

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.

By: Noah

Noah — Tue, 08 Jul 2008 18:24:44 +0000

Thanks for the info on that. And once again, thanks for the valuable article.

By: barneyb

barneyb — Tue, 08 Jul 2008 18:23:08 +0000

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.

By: Noah

Noah — Tue, 08 Jul 2008 18:14:25 +0000

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.

By: barneyb

barneyb — Tue, 08 Jul 2008 18:09:57 +0000

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.

By: Noah

Noah — Tue, 08 Jul 2008 18:07:03 +0000

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.

By: barneyb

barneyb — Wed, 04 Jun 2008 20:47:15 +0000

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.