Accepted answer

both are very similar but subversive is the "eclipse svn provider". i primarily use subversive because of a few convenient features:

grouping of history

when i'm browsing the history of a branch instead of just seeing a bunch of rows for every commit it can group commits by today, week, etc.

mapping of trunk, branches, and tags

subversive assumes the default svn layout: trunk, branches, tags (which you can change), so whenever you want to tag or branch it is one click and you provide the name of the tag or branch.

like i said these are minor differences that i just find convenient. both work great with mylyn, but overall there really isn't a whole lot of differences with these two extensions.

merging with subversive is a pain though (haven't tried subclipse), i've never been able to successfully merge. the preview of the merge is great but it would never complete the merge or it will take way to long. most of the time i complete merging through the command line without any issues.


if you are using zend studio 9, zend's implementation of eclipse, i recommend using subclipse instead of subversive which comes shipped with zend studio be default.

i have posted a problem with subversive and zend studio 9 and my solution of using subclipse instead on the zend forums.


i've also used both. i had the problem that i have around 150 projects on my workspace, and subversive would take an awful long time when i selected all plugins and said "synchronize repository". the ui would freeze for an extremely long time. i find subclipse to be more stable.

anyway, i combine the tools a lot. for some tasks like checking out whole branches i prefer the command line. for others i use tortoisesvn. i use subclipse mostly to view history and run comparisons directly on the tool, and occasionally to compare (i prefer beyond compare for that, though).


i had the same problem as some others even getting subversive to work, so i can't say if it's better than subclipse.

subclipse is really lacking when it comes to integration with eclipse for tags and branches. you can do them, but it's nowhere near as seamless as it is with cvs.


i've used both, and while subclipse has been flaky for me, subversive (at least with a previous version) locked out an account of my coworker when he accidentally put in the wrong credentials (the network login is used to access the subversion repository).

subclipse tends to get disorganized over time. if eclipse is not refreshed regularly subclipse seems to lose its file tracking information. honestly, though, since i have the easy explorer plugin, i use subversive (occasionally) for history and change information, but i easy explore and use tortoisesvn for commits and updates to the projects i know i've changed recently.


i've been using subversive since i upgraded to ganymede. i use it with eclipse in linux (ubuntu and fedora core), windows xp and mac os x.5. aside from some issues getting subversion 1.5.1 to use the right security libraries under mac os, i haven't had any problems. given that it has been adopted as an eclipse technology project, i am inclined to place my bets on it, in terms of long-term hopes.


i have not really used it, but it seems subversive supports "check out as", just like the built-in cvs support does.

like, to take a project from svn and be able to run it as a web project, one might be able to do so in one go. but to get the same result in subclipse, i just check out the sources and run:

mvn eclipse:eclipse -dwtpversion=2.0


i have just discovered that i cannot figure out how to view a properties diff with subclipse. in subversive you select two revisions in the history view, right-click and select compare properties from the popup. this is enough for me to stick with subversive.

the reason for trying to switch was subversive's strange behavior on os x: some automatic operation called 'svn cache update' hogged the cpu at abnormal levels after every 'svn update' run, always taking an annoyingly long time to complete.


fwiw, we are using an ancient version of svn server (1.4 something), and i seem to remember that at one point there was an update to subclipse that broke backward compatibility, and the gist was "nobody should be on such an old version of svn anyway".

subversive was the only one that seemed to be able to handle the older version. i can't remember the details, though, sorry.


we tried both in our team.

since subclipse (the one from galileo/helios) had some trouble authenticating our svn server via vas, we had no problem elsewhere, i.e. tortoisesvn client, browsers (except internet explorer 7).

so we installed subversive and the problem was resolved.


the advantage of subclipse over subversive... it actually works!

i used subclipse a long time ago when developing a collaborative plugin for eclipse that depended on subclipse. the subclipse part of the plugin was never a problem, although the whole ant thing still confuses me a bit, but the good part is you don't have to understand how the ant part works to know how to use it.

i am attempting to install pdt today (which is a whole other blog) and then subversive because, like many, it is portrayed as "the eclipse svn plugin". i was unable to install the four connectors at once, so i had to install them one at a time and one at a time i tried them, and one at a time it could not authenticate with the svn server.

i am trying pdt and subversive, because i want to save time, not spending more of it on different issues with a plugin.

i uninstalled subversive, installed subclipse, and connected just like that.

save yourself the time and hassle, go subclipse from the start.


for me neither is better or worse, but subversive is the default svn plugin in eclipse ganymede platform, so there's a chance that it's better integrated with eclipse.


as an addition to brendons answer:

we use subversion since version 1.5.1 and used subclipse first. but because we greatly depend on the merging feature, we switched to subversive which is more convenient and has a seperate reintegrate option in the merging dialog.

one bug that might hinder at merging is that if you select revisions explicitly, it doesn't take the last revision listed. e.g. "101-100" doesn't merge r100 and "100" thus doesn't merge anything at all. (version 0.7.5)

and it has uses the same indicators as the cvs plugin.


while i got both working with helios, i have a slight preference for subclipse because of its excellent support for bugtraq properties (details here).

the history view shows a separate column (titled bugtraq:label, displaying bugids), and the context menu has a dedicated action to "open bug url" (linking to bugtraq:url) -- i couldn't figure out how to access any of this info with subversive.


+1 subclipse
-1 subversive

subversive gets confused after even minor refactoring and has validation issues as above.

environment: sts 2.7.2 (based on galileo)


subversive has more advantages than the subclipse as listed below. but just one feature subversion does not have is so critical about using branches. so we have to use subclipse.

subversive advantages:

  • view and icons are more informative
  • after commit sync items are refreshed, committed file is closed.

subclipse advantage

  • ability to compare two branches


up until about may 2008 i was using subclipse, but due to issues with some projects, i've switched over to subversive and am using that with no issues. if you are doing something fancy like headless buckminster builds, then subversive is definitely the one to go with.


if you use tortoisesvn and regularly update the version you may find eclipse with subversive losing all svn information and throwing some scary errors.

the reason being the new version of tortoisesvn adds new meta data that eclipse subversive does not understand unless you also keep your eclipse svn connectors up to date as well.

i generally use the svnkit connector, so tortoisesvn 1.5.x will work with eclipse svnkit connector 1.5.x and tortoisesvn 1.6.x will work with eclipse svnkit connector 1.6.x.


i chose to go with subclipse since it is most closely associated with the subversion project and so more likely to better handle the core svn functionality. if at all it fails to perform any function then i have tortoisesvn as a backup.


just an update. i recently was reinstalling eclipse and was faced with choice of subclipse vs subversive. i, also, had my share of troubles trying to get subversive to work so i went for subclipse.

it installed perfectly on my linux 64 bit machine and is running just fine. i mapped most common functions like update, commit, .. to shortcuts and it's a blast. the merging is good too, although for bigger merges i still turn to tortoisesvn. i tried it with both 3.5 and 3.6, and they both work fine. i ended up using 3.5 because for some reason key binding were not working with 3.6.


if you are using one of them in your company and maybe even want to bundle them in own eclipse-based products, your life is much easier with subclipse, because it is available under the business-friendly eclipse public license.

subversive on the other hand needs so-called connectors to fully work. and those have separate and different licenses. so you may end up with two or three different licenses just for the subversive functionality, while all other eclipse plugins are just under that one epl. that's also the reason why those connectors are not hosted at

and that's why they are downloaded dynamically after the subversive installation (which also means that simply mirroring the update site does not give you a usable subversive offline installation in your company network).


if you are using svn+ssh as the protocol to access your repository i strongly suggest you to choose subclipse: subversive is not intelligent enough to remember your credentials properly and prompts you for username and private key every single time you update your working copy and also for each svn-external you may have set up.

the "remember credentials" options is broken in this context and has been since the first public release of subversive.


certainly both ide plugins have their issues. but neither precludes the parallel use of other solutions like tortoisesvn or command-line. i use all three for my projects at work.

the important thing to remember is that all your client svn software should use the same svn file format--which differs between versions of svn--or you are asking for trouble.

another issue we found is when your client software uses a different svn file format than the server. (by file format, i mean the way all the information is represented in all those seemingly invisible .svn files that effectively record what svn needs to know about your project files.) that can wreak havoc. there's a documented bug between 1.5 server and 1.6 clients, but i can't find the link right now.

we had issues running the superior (imo) subclipse 1.6 plugin because of incompatibilities with our svn 1.5.5 server. so we reverted to subversive. it works fine, albeit slow and somewhat buggy (but improving). we will switch to subclipse when our server is updated, though. and yes, we check out our projects with tortoisesvn and import them into eclipse (it's faster).

we found that, as other posters said here, it would not work if we ran newer versions of tortoisesvn that wrote files in 1.6.x format, but when we reverted to tortoisesvn 1.5.x, it worked just fine. the same was true of the command-line client (which we leverage with our ant tasks).


subclipse, because at least it works.

subversive has been a bucket of fail for me so far. it wouldn't play nice with all of my old projects i had checked out with subclipse.


i tried both of them, and both subclipse and subversive are awful. both are challenging to install. if you use subversive, you cannot use an external svn client.

however you need to have a svn client installed in eclipse to keep track of changes, and also to not corrupt your local repository.

i have subclipse installed, but use tortoisesvn to actually do comitting/tagging/branching/merging.


they both have pretty heinous warts, but i couldn't get subversive to work with a project i had checked out from the command-line, and that was a show-stopper for me.


i actually think both of them kind of suck. using tortoisesvn is a far better solution in my opinion. it's far more robust and tends to just work better, and i've always had integration issues with subclipse and subversive.


i would say subclipse, as i couldn't even get subversive working ;)


if you do much merging with subversion then you will probably prefer collabnet desktop - eclipse edition. you have to register an account with collabnet to get the download, but it is free. it is essentially subclipse with a better merge ui.

i am not affiliated with collabnet.

collabnet has made their improved merge client available to non-registered users of subclipse. you get it by selecting the collabnet merge client feature when installing subclipse from the update site.


after reading this post, i changed to subclipse hands down.


with every new version of eclipse, i install subversive, because it's the standard provided by eclipse. and every time, it has issues recognizing my pre-existing projects.

so i end up uninstalling subversive and installing subclipse instead, which works marvellously. i also frequently use svn from the command line as well as in eclipse, and subclipse has no problems with this.


i will take a crack at answering this. i am a project lead for subclipse, and i manage all of the releases, etc. for the project. so my biases are obvious.

i am not going to talk too much about subversive. clearly, there are users that use it and like it. functionally the products are very similar as both are mature products.

one thing i do want to comment on is this notion that somehow subversive is the "official eclipse" plugin. that is just not true, as there is no such designation. eclipse is an open-source foundation and any project that wants to follow their rules, process and ip requirements, etc. can host their project with the foundation. that does not make you any more or less official than any other plugin.

i will also note that subversive has remained in the "incubation" phase since its inception, and it does not appear to me that it will ever meet the requirements for graduation. as you can see here, there has been only one committer on the project and commit activity has dwindled to very low levels.

subversive - svn team provider

so why should you use subclipse? we are actively involved with subversion itself. i am a subversion pmc member and help maintain the java language bindings so that we (and other projects like subversive) can use the api.

we work directly with subversion to define and improve the api and make sure necessary features are exposed to clients like subclipse. we also work closely and collaborate with the visual studio integration (ankhsvn) and tortoisesvn teams to make sure there is a relatively consistent user experience across clients.

subclipse is still actively maintained and we maintain support for eclipse versions 3.2 to 4.2. we are always trying to listen to feedback and incorporate ideas from the community. the recent 1.8.x releases include internal changes that greatly improve performance of eclipse when working with large projects (that is when you really see it).

subclipse has led the way in areas like merge tracking support, where we worked closely with the subversion team in first adding this feature in 1.5 and then evolving it in subsequent releases. we were often the initial consumers of new api and provided the project with the feedback needed to harden the feature. we also introduced a graphical revision graph feature a couple years ago, becoming the first to bring this long asked for feature to eclipse users.

if there are specific ui features in subversive that people would like to see made in subclipse, i would encourage you to visit our community and engage in our discussion forums. maybe other users share your views and we can improve the ui together.

forum [subclipse-users].

eclipse 4.2 is the latest release at the time of this post, but it is safe to assume that subclipse will support all future eclipse releases as they are made.

Related Query

More Query from same tag