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
allows
this). I frequently want to refer to the changes I made when writing
the
commit comment.
- It would be nice to have the new revision printed at the end of the
commit
output in the console (similar to the command line) - at present it's
not
clear when the operation has finished.
- It would be nice to have the option of bringing the console to the
front
after all operations, not just errors.
One thing which doesn't appear in the list at all is handling of
svn:externals.
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
to
get it checked out
- see externals in the repository browser (as links, or something)
Cheers,
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:
>
> 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.
> ______________________________________________________________
> _______________
>
> ______________________________________________________________
> __________
> This email has been scanned for all viruses by the MessageLabs Email
> Security System.
> ______________________________________________________________
> __________
>
>
Received on Mon Nov 8 21:02:13 2004