Unless someone else is already working on it, we are going to take a crack
at showing the items in the commit dialog, as Tortoise does. If we get
that done, we will also try to tackle some of the other items related to
the commit dialog, such as the bug tracking integration.
Cédric Chabanois <firstname.lastname@example.org> wrote on 11/05/2004 07:21:27 PM:
> 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
> >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
> >forward to any comments. I would like to see some kind of effort made
> >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
> >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
> >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
> >Subclipse. The most current builds of each product as of November 6,
> >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
> >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
> >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
> >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
> >in an unencrypted format in the Subversion configuration area.
> >needs to offer the ability to provide a new/updated password in its
> >repository configuration.
> >** Import
> >This feature works great in Tortoise. The equivalent Subclipse
> >Share Project, has gotten better. Subclipse doesn’t do an import,
> >they create a “stub” for your Eclipse project in the repository and
> >turn your project into a WC. You then have to do normal add/commit to
> >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
> >could probably benefit from a final step that commits all of the files.
> >do not think the current behavior is real obvious.
> >** Checkout
> >No issues in Tortoise. Subclipse has more underlying issues to deal
> >that complicate the process. There have also been some Subversion bugs
> >with branches that complicate it as well. In general, things are
> >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
> >end of the process, Tortoise provides the option to view the log,
> >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
> >not exist in Subclipse. I have never used this feature in Tortoise,
> >it seems like it might be useful. Perhaps Subclipse could make the
> >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
> >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
> >to see this information if it were desired. It would be nice of
> >could mimic more of the Tortoise dialog.
> >Tortoise also has a number of advanced features that appear in the
> >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
> >that are used by Tortoise.
> >** Revert
> >Revert has the same basic issues and conclusions as update. Both
> >are fine.
> >** Add/Delete/Rename
> >Add/Delete/Rename is pretty much the same as Revert and Update. A
> >advantage that Subclipse has is that it can hook into the Eclipse
> >delete/rename functions and just work automatically. With Tortoise,
> >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
> >“Stop on Copy” feature of svn log accessible which is nice for
> >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
> >are generally very similar. Tortoise has a couple of additional
> >like Show Properties and the ability to view the repository at a
> >** 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
> >Subclipse could use some improvements to make creating branches and
> >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
> >UI to perform a merge into your WC. It also exposes the dry-run option
> >that you can preview the outcome. Subclipse needs this feature.
> >** Export
> >Tortoise has this feature. It doesn’t really seem needed in Subclipse;
> >certainly is not high-priority.
> >** Relocate
> >You use this option when your repository URL changes. This is a weak
> >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
> >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
> >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
> >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
> >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
> >in that the Eclipse viewer does all of the work, therefore it has
> >with Subversion-specific idiosyncrasies that it would not have if it
> >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
> >to define an external program for this operation that they could tie
> >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
> >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,
> >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
> >in dealing with branching, merging and resolving conflicts. I do not
> >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
> >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
> >WC. A tool to resolve conflicts is very much needed and integration
> >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.
> To unsubscribe, e-mail: email@example.com
> For additional commands, e-mail: firstname.lastname@example.org
> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management
> Services powered by MessageLabs.
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
Received on Thu Nov 11 02:54:48 2004