I started a todo list based on your document
>With a goal of being able to identify what is left to be done to get
>Subclipse to a "1.0" state, I thought it would be useful to compare what
>you can do in Subclipse, with what you can do in TortoiseSVN.
>You can download this document in MS Word format from here:
>I have also attempted to create a plain text version that follows. I look
>forward to any comments. I would like to see some kind of effort made to
>come up with a list of what needs to be done to get us to that stage.
>Creating this list might help stimulate more activate involvement in the
>project. Along those lines, I also think that I finally have some
>resources I can make available to help us get there, although it will take
>us some time to learn the architecture and coding style.
>Comparing TortoiseSVN and Subclipse
>This document is a brief feature by feature comparison of TortoiseSVN and
>Subclipse. The most current builds of each product as of November 6, 2004
>were used for this comparison with Subversion 1.1.1 as the underlying
>The goal of this document is to use TortoiseSVN as a base for identifying
>what additional features and work need to be added to Subclipse to get it
>to the “1.0” stage and beyond. The features are not presented in any
>Both products support all of the repository access methods. I do not know
>if Subclipse has any issues when SSH is needed. I do know (or at least
>think) that Subclipse lacks UI relating to accepting digital certificates.
> This can generally be worked around by using the command line client to
>initially establish credentials and accept the certificates.
>TortoiseSVN has a nice Windows-specific feature in that it will encrypt
>your cached credentials.
>Subclipse could offer a similar feature by using Java to encrypt the
>credentials and save them in the workspace. Then use those credentials
>with Subversion in a way that the Subversion libraries do not cache them
>in an unencrypted format in the Subversion configuration area. Subclipse
>needs to offer the ability to provide a new/updated password in its saved
>This feature works great in Tortoise. The equivalent Subclipse feature,
>Share Project, has gotten better. Subclipse doesn’t do an import, instead
>they create a “stub” for your Eclipse project in the repository and then
>turn your project into a WC. You then have to do normal add/commit to get
>stuff into the repository. The basic idea is probably appropriate for
>Eclipse, but it could use some UI refinement.
>It is hard to implement the Project/trunk structure from Subclipse. The
>Share Project Wizard could probably make this easier. Finally, the wizard
>could probably benefit from a final step that commits all of the files. I
>do not think the current behavior is real obvious.
>No issues in Tortoise. Subclipse has more underlying issues to deal with
>that complicate the process. There have also been some Subversion bugs
>with branches that complicate it as well. In general, things are working
>pretty well now, but there is probably still some room for improvement.
>Both products provide this option. Tortoise shows the activity in a
>dialog, Subclipse can optionally show the activity in a console. At the
>end of the process, Tortoise provides the option to view the log, meaning
>the equivalent of svn log. This is a nice feature in that it makes it
>easy for the developer to not only get the latest code, but read the
>commit messages related to those updates.
>Tortoise also has a second option, Update to Revision. This feature does
>not exist in Subclipse. I have never used this feature in Tortoise, but
>it seems like it might be useful. Perhaps Subclipse could make the Update
>option open a dialog that lets you select HEAD or a specific Revision?
>All of this being said, what Subclipse does is probably appropriate for
>its environment. Perhaps the Update to Revision option could be added at
>Both products provide this option, and both products automatically
>recognize un-versioned files and provide the ability to add them to the
>commit. Tortoise shows all of what will be committed, including
>adds/deletes and property changes. The Subclipse dialog does not,
>although they do have a Pending Operations view that you could run first
>to see this information if it were desired. It would be nice of Subclipse
>could mimic more of the Tortoise dialog.
>Tortoise also has a number of advanced features that appear in the commit
>1) Integration with bug tracking tools as described here:
>2) Ability to define a minimum commit message length.
>3) Ability to show a line-width marker. Some projects do not want
>any line of a commit message to be more than 80 characters. This is a
>guide to help with that.
>4) Message templates. The ability to paste in a standard template
>Ultimately, Subclipse ought to be able to provide all of the same
>features, and base them on the same in-repository configuration properties
>that are used by Tortoise.
>Revert has the same basic issues and conclusions as update. Both products
>Add/Delete/Rename is pretty much the same as Revert and Update. A small
>advantage that Subclipse has is that it can hook into the Eclipse
>delete/rename functions and just work automatically. With Tortoise, you
>have to remember to use the Tortoise Delete/Rename option and not the
>native Windows delete/rename.
>Both products have this feature. Tortoise has some nice additions:
>1) Integration with bug tracking tools as described here:
>2) They only initially fetch the history from the most recent X
>revisions. There is an option to then get the rest. They also make the
>“Stop on Copy” feature of svn log accessible which is nice for branches.
>3) They recently added an experimental “Statistics” dialog. This
>creates some graphs based on the information currently retrieved by the
>** Repository Browsing
>Both products have the feature, there are some subtle differences but they
>are generally very similar. Tortoise has a couple of additional options
>like Show Properties and the ability to view the repository at a non-HEAD
>** Check for Updates
>This is an option that shows the changes in the local WC and the
>repository in one dialog. It is kind of a preview of what would happen
>with an update. Subclipse will have this feature, perhaps in an even
>better form, when the Synchronize with Repository option is completed.
>Right now, this feature is missing from Subclipse.
>** Clean Up
>This runs svn clean, which I have never quite understood what it does.
>Anyway, Subclipse does not have this option. It seems like it would be
>easy enough to add it.
>Tortoise has an option to create a branch or tag from the Working Copy.
>Both products have UI to copy from within the Repository browser. I think
>Subclipse could use some improvements to make creating branches and tags a
>little more obvious.
>This is perhaps the biggest hole in Subclipse. This is a significant
>feature of Subversion. The switch option should be implemented in
>This is perhaps the second biggest hole in Subclipse. Tortoise provides a
>UI to perform a merge into your WC. It also exposes the dry-run option so
>that you can preview the outcome. Subclipse needs this feature.
>Tortoise has this feature. It doesn’t really seem needed in Subclipse; it
>certainly is not high-priority.
>You use this option when your repository URL changes. This is a weak area
>of Subclipse. It is not high priority, but it is worth improving.
>** Create/Apply Patch
>I have never used this feature in Subclipse, but it does appear to provide
>it. I assume it works properly. Creating patches is easy, as svn diff
>does all of the work. Subversion does not provide anything to apply a
>patch, so that is usually where work is needed. Tortoise provides the
>excellent Tortoise Merge tool that handles all of the details. If there
>were an area Subclipse has a problem, this would likely be it. However,
>perhaps they were able to leverage whatever code the CVS provider uses in
>Eclipse? I should probably test this some more.
>Both products provide a custom viewer for this feature. I like some of
>the stuff that Tortoise does with colors, but the Subclipse implementation
>also has its good points.
>** Properties Management
>Both products implement this well. One thing that Tortoise does that
>Subclipse should implement, is to show all known properties in a drop-down
>in the Add dialog. For example, the properties commonly used by
>Subversion, and also the ones used to implement bug tracking as well as
>control the log messages in the commit dialog.
>Both products offer nice compare viewers. Subclipse has a small problem
>in that the Eclipse viewer does all of the work, therefore it has problems
>with Subversion-specific idiosyncrasies that it would not have if it could
>use the output of svn diff. There is some room for improvement.
>Otherwise, the Eclipse compare is nice.
>** Merge Viewer/Edit Conflicts
>Subclipse does not provide anything to assist with editing conflicts.
>Tortoise provides Tortoise Merge which is an excellent tool. This is a
>very weak point in Subclipse. I would suggest that they add a preference
>to define an external program for this operation that they could tie into
>the UI. On Windows, users could use Tortoise Merge, on Linux there are
>tools like Meld that can do the job. Of course an Eclipse-based solution
>would be welcome, but when it comes, you just add a default value of
>“Built-in” to the preference.
>Both products have the ability to mark a conflict as resolved.
>Both products can decorate files and folders to show status. Both
>products have performance issues with this feature, and they both
>continually strive to improve the performance.
>** General UI
>Both products integrate well into their environments. Subclipse could
>probably benefit by providing some fresh icons for some of their views, as
>well as supplying icons for the menu actions. They could just use the
>icons from Tortoise with proper credit being given.
>Core functionality between the two products is very comparable. To an
>independent observer, Tortoise would almost always appear to have more
>polish, but in most cases the way Subclipse operates is very appropriate
>for the Eclipse environment. The main areas that Subclipse needs work are
>in dealing with branching, merging and resolving conflicts. I do not know
>if the Synchronize Repository work is in any way laying the ground work
>for these features, but I tend to doubt it. I think more focus should be
>placed on general branch/tag creation, as well as the actions to switch
>the WC to another location, and a Merge action to merge branches into the
>WC. A tool to resolve conflicts is very much needed and integration with
>an external tool seems like a very simple way to get something in place
>Finally, since I was heavily involved in the bug tracking integration
>spec, I would very much like to see it implemented in Subclipse sooner
>rather than later. Tortoise offers an excellent reference implementation
>to go by.
>Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
Received on Sat Nov 6 11:21:27 2004