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

Getting to 1.0 - a comparison of features with TortoiseSVN

From: Mark Phippard <MarkP_at_softlanding.com>
Date: 2004-11-05 18:04:25 CET

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:

http://support.softlanding.com/download/Subclipse.doc

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.

Thanks

Mark

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
base.

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
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 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
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 improvement.

** 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
dialog.

1) Integration with bug tracking tools as described here:
http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
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:
http://svn.collab.net/repos/tortoisesvn/trunk/doc/issuetrackers.txt
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
revision.

** 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.

** 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
Subclipse.

** 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 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.

** 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 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
soon.

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 04:04:25 2004

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