I talked a few days back about my preferred Eclipse plugins, and that my chosen Subversion plugin was Subclipse. Subclipse has been going for many years which is why I instantly gravitated to it without really thinking about it, but David was good enough to recommend in the comments that I should take a look at an alternative: Subversive. Since Subclipse has been working just fine for me it took me a while to get around to doing it, but I finally did today.
One thing that instantly strikes you as soon as you go to the Subversive site is that it’s now an Eclipse ‘incubator project’, which means it’s one step away from becoming part of the core Eclipse distribution – this is despite the fact that Subclipse is the longer running project. Indeed if you Google for ‘subversion eclipse’, Subclipse is hit #1 while Subversive is down at rank #6 – so I was now very curious as to why Subversive had been picked over Subclipse. As it turns out, it sounds like some of it was related to IP, but even so you have to believe that they wouldn’t have picked a less functional project.
So, I tried it out. Annoyingly, switching SVN provider disconnected all my projects from their repositories (grr) but luckily I didn’t have any local changes and it was easy enough to reestablish the connection. At first, most things looked roughly the same, the project icons were the same, menu structure very similar – after all, the connector is mostly a back-end after all. However, a single feature had an undeniable psychological impact on me – that Subversive is smart about detecting & interpreting common Subversion folder structures, like this:
In contrast, Subclipse just displays those as simple folders. It’s silly really, but a little difference like that is enough to make me prefer Subversive – it won’t affect my workflow at all, but it just makes me feel comfier. The moral is of course that users are incredibly fickle in their allegiances. especially when it comes to pretty icons 
For the record, Subversive has some other nice features too, such as being able to group history views by date and to interleave repository history with Eclipse’s local save history. On a subjective level the Team menu feels a little more polished too, even though the options are exactly the same – it’s those darn icons again no doubt. There’s nothing here that’s a killer blow, and Subclipse would have continued to serve me just fine I’m sure, but a few niceties and the the fact that it’s an incubation project now have meant I’ve switched allegiance to Subversive. I hope Subclipse doesn’t hate me for it.
February 20th, 2008 at 7:57 pm
Actually, Subclipse does hate you now
Just a few points (I am happy that you are happy with Subversive).
Eclipse did not pick one plug-in over the other. Eclipse does not pick anything. Projects make proposals to become an Eclipse.org project and as long as they follow the guidelines they are generally approved. We made the conscious decision to not make the Subclipse project part of Eclipse.org. We are happy to be aligned with the Subversion project as that is where most of the work we need to do happens. Subversion 1.5 contains a number of significant enhancements and fixes that came out of the Subclipse project and requests and code we contributed.
Also, Subversive will never be part of the Eclipse core. Eclipse is really moving the other direction, they even removed CVS from the core. There will likely be future efforts coming out of the Eclipse Packaging Project (EPP) where you can build or obtain Eclipse packages that include Subversion and/or CVS.
Finally, Subclipse added support for custom icon sets a long time ago. We ship using the same defaults as CVS (give or take a couple differences). We also include the TortoiseSVN and Subversive icon sets for people that prefer one of those.
The next release of Subclipse, which includes Subversion 1.5 features, is going to be huge. You can grab a preview of it here, including the powerful new merge client that CollabNet has produced on top of Subclipse.
http://merge-tracking.open.collab.net/
If you can’t tell, we want you back!
February 21st, 2008 at 9:34 am
Thanks for the clarifications Mark! Very interesting, as an outsider it’s quite hard to figure out exactly what the conditions & implications of being an incubator project are, and several mailing list posts I read seemed to state that Eclipse was looking for a built-in SVN connector.
I will certainly try out the next release of Subclipse. I know I can change the icon sets, but is there any chance it will detect the trunk/branches/tags structure in the browse dialogs and use dedicated icons too? It’s a silly little thing, but it’s surprising how much impact it has.
February 21st, 2008 at 2:07 pm
Eclipse is not a person or even really a set of people. There is no one at Eclipse that is going out and thinking of things they want. Projects have to propose themselves. The Eclipse community, meaning people like yourself, have certainly expressed the desire to have Subversion support over the years. When it comes down to it, Eclipse is mainly a hosting service for projects, plus the community around them. The Subclipse project simply decided we were happy where we are, and that we could better serve our users and create a better product if we were not part of Eclipse.
I have never seen the value in that feature of Subversive. Other than the icons, I have not seen how they actually make use of this feature to provide anything special. It seems like all of their dialogs, like Switch and Merge still require you to enter URL’s. The support we added for this years ago at least allows you to just pick a branch/tag from a list and have it transform the URL for you: http://subclipse.tigris.org/branch_tag.html
Subclipse is an open source project and community. If our members want to propose a feature and gather support on how it should work, we are always open to listen.
Mark
February 21st, 2008 at 2:32 pm
You can just hit the ‘browse’ in the Switch / Merge etc (or just use the drop-down for previous URLs), and that dialog looks pretty much like Subclipse does – but the difference is that in Subclipse, I have to tell it what’s a branch and a tag via the ‘Configure Branches / Tags’ dialog – I don’t have to do that in Subversive because I (like most people) just use the standard trunk/branches/tags setup. It also uses that knowledge to tag projects in Eclipse – if I’ve checked out from a branch it will say ‘Branch: branchname’ in the label decoration instead of needing a full repository URL. It seems to me a useful feature in Subclipse would be to detect that structure and automatically configure branches / tags from it.
I also quite like their interactive Merge facility – ie you end up at the Synchronize view to preview the effect of merging a branch. It has a small bug though that I found today (raised), but the idea is good – Subclipse does an immediate merge (unless there’s an option I missed) – which is how I usually do branch merges anyway but the Synchronize view was quite a nice touch – whether I’d want to use it all the time or not is something I’ll have to review.
I fully realise that as an open source project, what gets included is all about where the individual community project leadership wants to be going. I’m not going to tell you what I think you should do – I’m just giving you an insight into things I, as a user, quite liked about Subversive. I still like Subclipse, but they’re really very similar and so inherently it’s going to be fairly insignificant things that influence which I use. Personally I can (and have) happily use either right now, there’s just a couple of super-minor things that make me prefer Subversive at this particular instant. If I find more bugs though that might change
February 21st, 2008 at 2:38 pm
Just noticed this: Subversive doesn’t display tags in the history view whilst Subclipse does. That’s pretty handy.
February 21st, 2008 at 2:48 pm
I think I view things a little differently than you. Because Subclipse is an open-source project we depend on our community to help us decide what to do. Sure, in the end the people that write the code make the decisions, but we also base what we do on what the community says it wants. If the community wants a feature like you describe above they need to tell us and describe what it should do and how it should work. You did some of that in the last comment. We need more specifics like that.
The feature we have in Subclipse does things that detecting the structure cannot really do well. For example, I believe that Subversive is not able to annotate the History view with details on tags as we have in Subclipse.
As for choosing a tag in a dialog, ours would work the same as theirs even without using this special feature. We just do not have special icons on the folders.
I do not say this to argue with you. I am sure there is value in their feature. We would surely enhance subclipse in this area if some specific feature requests come in that show the value it would add.
The Subversive interactive merge feature is a cool idea, but it does not work. When you look at the diff of a file it winds up doing a 3-way diff on the entire revisons of the file, not just the parts that would actually be merged.
Here is a link to what we are doing with merge:
http://merge-tracking.open.collab.net/servlets/ProjectProcess?pageID=3709&freeformpage=Merge%20Client%20Overview
Finally, I completely understand that there are not a lot of differences between these products and which one someone uses is going to come down to personal differences. I think it is good that we have two good options.
Mark
February 21st, 2008 at 3:08 pm
You’re right about the annotation of tags in the history, I spotted that just recently. I hadn’t noticed the 3-way merge issue, that’s probably because my merge tests weren’t that complex.
The merge features you linked look good. I actually think the most useful merge feature I could have would be one which deals with the most common merge case I have (and I suspect most people have) – that of merging changes from a branch into the trunk, covering revisions from the last time I merged to the branch’s head. I never found a CVS or SVN tool that really makes this as simple as it should be, in terms of the ‘markers’ you tend to want to set for the merge. That is you really want:
- a marker (FROM) that represents the last merge point on the branch. Luckily in SVN this is just a single revision number (CVS needs a tag on every file)
- a marker (TO) that represents the ‘merge to’ point on the branch. This is only needed if there’s a chance that someone else will commit something to the branch during the merge. Again, just a case of a revision number rather than implictly using ‘HEAD’
Obviously you set ‘TO’ when you start the merge process, and after the merge is committed you set FROM to what TO was, ready for next time.
Typically I’ve done this in CVS using tags, and in SVN either by manually making a note of revision numbers (in the commit logs, or as properties). I’d love to be able to have an automated process that controls this though, it would make it a lot more like Perforce which generally tracks cross-branch merges better than either CVS or SVN.
I guess my blog isn’t the best place to be having this debate, but I started so I’ll finish.
February 21st, 2008 at 3:36 pm
That merge link I sent you does what you asked, although it is really part of the SVN 1.5 merge tracking feature. Basically, you will not need to specify revisions at all in those sort of merge scenarios.
You will not need to do anything special, SVN will take care of the details and the UI we created allows you to leverage that ability.
Mark
February 21st, 2008 at 3:46 pm
Ah, that’s great, I didn’t realise SVN was going to start managing that in the back end. I’m looking forward to 1.5 then!