[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Getting to 1.0 - a comparison of features with TortoiseSVN

From: CÚdric Chabanois <cchabanois_at_no-log.org>
Date: 2004-11-14 23:27:28 CET

I added some of your ideas in the todo list.
I also added some issues to issue tracker for minor modifications
(issues #178 and #179)



>HI Mark,
>What an excellent list. I only have a few extras which bother me on a
>regular basis:
> - It would be nice for the commit dialog to be modeless (if Eclipse
> this). I frequently want to refer to the changes I made when writing
> commit comment.
> - It would be nice to have the new revision printed at the end of the
> output in the console (similar to the command line) - at present it's
> clear when the operation has finished.
> - It would be nice to have the option of bringing the console to the
> after all operations, not just errors.
>One thing which doesn't appear in the list at all is handling of
>I know technically this is just a property like any other, but it has
>quite a
>fundamental effect on behaviour. It would be nice to
> - see when a directory is due to an svn:external
> - add an external by browsing the repository and then do an svn update
> get it checked out
> - see externals in the repository browser (as links, or something)
>Ian Brockbank
>Applications Software Team Leader
>e: ian.brockbank@wolfsonmicro.com / apps@wolfsonmicro.com
>scd: ian@scottishdance.net
>t: +44 131 272 7145
>f: +44 131 272 7001
>>-----Original Message-----
>>From: Mark Phippard [mailto:MarkP@softlanding.com]
>>Sent: 05 November 2004 17:04
>>To: dev@subclipse.tigris.org; users@subclipse.tigris.org
>>Subject: Getting to 1.0 - a comparison of features with TortoiseSVN
>>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
>>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
>>particular order.
>>** Connectivity
>>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
>> 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
>>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
>>repository configuration.
>>** Import
>>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.
>>** Checkout
>>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
>>** Update
>>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
>>some point.
>>** Commit
>>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
>>for messages.
>>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
>>Revert has the same basic issues and conclusions as update.
>>Both products
>>are fine.
>>** Add/Delete/Rename
>>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.
>>** Log/History
>>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
>>log command.
>>** 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
>>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.
>>** Branch/Tag
>>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.
>>** Switch
>>This is perhaps the biggest hole in Subclipse. This is a significant
>>feature of Subversion. The switch option should be implemented in
>>** Merge
>>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.
>>** Export
>>Tortoise has this feature. It doesn't really seem needed in
>>Subclipse; it
>>certainly is not high-priority.
>>** Relocate
>>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.
>>** Blame/Annotate
>>Both products provide a custom viewer for this feature. I
>>like some of
>>the stuff that Tortoise does with colors, but the Subclipse
>>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.
>>** Compare/Diff
>>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.
>>** Decorators
>>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.
>>***** Conclusions
>>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
>>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
>>to go by.
>>Scanned for SoftLanding Systems, Inc. by IBM Email Security
>>Management Services powered by MessageLabs.
>>This email has been scanned for all viruses by the MessageLabs Email
>>Security System.
>To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
>For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Mon Nov 15 09:27:28 2004

This is an archived mail posted to the Subclipse Dev mailing list.