Login | Register
My pages Projects Community openCollabNet

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

subclipse
Discussion topic

Hide all messages in topic

All messages in topic

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

Author cchab
Full name chabanois cédric
Date 2004-11-14 14:27:28 PST
Message 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)

Thanks,

Cédric

>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 dot brockbank at wolfsonmicro dot com / apps at wolfsonmicro dot com
>scd: ian at scottishdance dot net
>t: +44 131 272 7145
>f: +44 131 272 7001
>
>
>
>
>
>
>>-----Original Message-----
>>From: Mark Phippard [mailto:MarkP at softlanding dot com]
>>Sent: 05 November 2004 17:04
>>To: dev at subclipse dot tigris dot org; users at subclipse dot tigris dot 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.softl​anding.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.ne​t/repos/tortoisesvn/​trunk/doc/issuetrack​ers.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.ne​t/repos/tortoisesvn/​trunk/doc/issuetrack​ers.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.
>>____________​____________________​____________________​__________
>>__________
>>
>>
>>
>>
>
>----------------​--------------------​--------------------​-------------
>To unsubscribe, e-mail: users-unsubscribe@su​bclipse.tigris.org
>For additional commands, e-mail: users-help at subclipse dot tigris dot org
>
>
>
>


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Chris Eldredge <chriseldredge at comcast dot net>
Full name Chris Eldredge <chriseldredge at comcast dot net>
Date 2004-11-09 07:53:54 PST
Message > I meant to have the patch open in Notepad, gEdit, TextEdit.app or whatever
> text editor you have on your OS. Since it would be outside of Eclipse, it
> would not be blocked by the modal dialog.

You could also commit using command line svn or TortoiseSVN from outside Eclipse. But I guess
that would kinda defeat the purpose of having an Eclipse plugin, right? :)

Actually that's what I do right now- commit from Tortoise, because it shows which files have been
modified and if you double-click one, you get a diff against the Base revision. I use that every
single time I commit.

Chris.


--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author David Corbin <dcorbin at machturtle dot com>
Full name David Corbin <dcorbin at machturtle dot com>
Date 2004-11-09 07:22:45 PST
Message On Tuesday 09 November 2004 10:17, Mark Phippard wrote:
> David Corbin <dcorbin at machturtle dot com> wrote on 11/09/2004 10:13:23 AM:
> > > I do not know if making the dialog modeless could cause any other
> > > problems. For the sake of discussion, let's just say that it would
>
> cause
>
> > > other problems. Couldn't you use the Create Patch option prior to the
> > > commit, and then have the patch file open in a text editor along side
>
> the
>
> > > commit dialog?
> >
> > Perhaps, but then If the patch is larger than then display, I still
>
> can't
>
> > scroll it. And that would be a very cumbsome process.
>
> I meant to have the patch open in Notepad, gEdit, TextEdit.app or whatever
> text editor you have on your OS. Since it would be outside of Eclipse, it
> would not be blocked by the modal dialog.
>

True enough. Now I'm down to "cumbersome". I was just explaining what I'd
like. CVS doesn't do it, and I get by, but it would be nice if it would
(assuming no complications).

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Mark Phippard <MarkP at softlanding dot com>
Full name Mark Phippard <MarkP at softlanding dot com>
Date 2004-11-09 07:17:34 PST
Message David Corbin <dcorbin at machturtle dot com> wrote on 11/09/2004 10:13:23 AM:

> > I do not know if making the dialog modeless could cause any other
> > problems. For the sake of discussion, let's just say that it would
cause
> > other problems. Couldn't you use the Create Patch option prior to the
> > commit, and then have the patch file open in a text editor along side
the
> > commit dialog?
>
> Perhaps, but then If the patch is larger than then display, I still
can't
> scroll it. And that would be a very cumbsome process.

I meant to have the patch open in Notepad, gEdit, TextEdit.app or whatever
text editor you have on your OS. Since it would be outside of Eclipse, it
would not be blocked by the modal dialog.

Mark



____________________​____________________​____________________​_________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
____________________​____________________​____________________​_________________

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author David Corbin <dcorbin at machturtle dot com>
Full name David Corbin <dcorbin at machturtle dot com>
Date 2004-11-09 07:13:23 PST
Message On Tuesday 09 November 2004 09:45, Mark Phippard wrote:
> David Corbin <dcorbin at machturtle dot com> wrote on 11/09/2004 09:40:31 AM:
> > On Monday 08 November 2004 09:21, Mark Phippard wrote:
> > > "Ian Brockbank" <Ian.Brockbank@wo​lfsonmicro.com> wrote on 11/08/2004
> > >
> > > 05:02:13 AM:
> > > > - 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 seems like the Synch view might make this easier? Also, if the
>
> commit
>
> > > dialog contained the list of files being committed, as Tortoise does,
> >
> > I'd like this too. Listing the files wouldn't help at all (for me). I
>
> want to
>
> > be able to do a "diff" for each file to see what should be said in the
> > comment.
>
> I do not know if making the dialog modeless could cause any other
> problems. For the sake of discussion, let's just say that it would cause
> other problems. Couldn't you use the Create Patch option prior to the
> commit, and then have the patch file open in a text editor along side the
> commit dialog?

Perhaps, but then If the patch is larger than then display, I still can't
scroll it. And that would be a very cumbsome process.

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Mark Phippard <MarkP at softlanding dot com>
Full name Mark Phippard <MarkP at softlanding dot com>
Date 2004-11-09 06:45:27 PST
Message David Corbin <dcorbin at machturtle dot com> wrote on 11/09/2004 09:40:31 AM:

> On Monday 08 November 2004 09:21, Mark Phippard wrote:
> > "Ian Brockbank" <Ian.Brockbank@wo​lfsonmicro.com> wrote on 11/08/2004
> >
> > 05:02:13 AM:
> > > - 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 seems like the Synch view might make this easier? Also, if the
commit
> > dialog contained the list of files being committed, as Tortoise does,
>
> I'd like this too. Listing the files wouldn't help at all (for me). I
want to
> be able to do a "diff" for each file to see what should be said in the
> comment.

I do not know if making the dialog modeless could cause any other
problems. For the sake of discussion, let's just say that it would cause
other problems. Couldn't you use the Create Patch option prior to the
commit, and then have the patch file open in a text editor along side the
commit dialog?

Mark


____________________​____________________​____________________​_________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
____________________​____________________​____________________​_________________

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author David Corbin <dcorbin at machturtle dot com>
Full name David Corbin <dcorbin at machturtle dot com>
Date 2004-11-09 06:40:31 PST
Message On Monday 08 November 2004 09:21, Mark Phippard wrote:
> "Ian Brockbank" <Ian.Brockbank@wo​lfsonmicro.com> wrote on 11/08/2004
>
> 05:02:13 AM:
> > - 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 seems like the Synch view might make this easier? Also, if the commit
> dialog contained the list of files being committed, as Tortoise does,

I'd like this too. Listing the files wouldn't help at all (for me). I want to
be able to do a "diff" for each file to see what should be said in the
comment.

David

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Ian Brockbank <Ian dot Brockbank at wolfsonmicro dot com>
Full name Ian Brockbank <Ian dot Brockbank at wolfsonmicro dot com>
Date 2004-11-09 02:36:13 PST
Message Hi Mark,

> > - 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 seems like the Synch view might make this easier? Also,
> if the commit
> dialog contained the list of files being committed, as Tortoise does,
> would that help? Or did you need to be able to access the
> content of the
> source?

What I want to do is check exactly what's been changed so I can give
details in the commit message. The Subversion convention is to list
each function that has changed, and I don't always remember... (Not
that I do much on the Subversion code, but it's still useful to add that
level of detail at times).

So yes, I want access to the code itself.

Cheers,

Ian Brockbank
Applications Software Team Leader
e: ian dot brockbank at wolfsonmicro dot com / apps at wolfsonmicro dot com
scd: ian at scottishdance dot net
t: +44 131 272 7145
f: +44 131 272 7001

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author "Cédric Chabanois" <cchabanois at natsys dot fr>
Full name "Cédric Chabanois" <cchabanois at natsys dot fr>
Date 2004-11-08 08:07:42 PST
Message >> Some comments on this discussion
>>
>> 1. Conflict Editor
>> Eclipse already has a compare/conflict editor. The editor we use to
>> compare with BASE or remote can be made to work as a three way editor
>> (like the cvs plugin) comparing local with remote using a common
>> ancestor (BASE).
>
> This could be used in the synch view, but if I just do an update and a
> conflict is created in my working copy, could it be used then? I still
> like the idea of adding a preference to launch an external program. As I
> said, there could be a default of "built-in" once we have a way to do this
> within Eclipse.

I added the possibility to launch an external program for conflicts
resolution last week-end.
I will now do the built-in stuff


Cédric




--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Mark Phippard <MarkP at softlanding dot com>
Full name Mark Phippard <MarkP at softlanding dot com>
Date 2004-11-08 06:21:55 PST
Message "Ian Brockbank" <Ian.Brockbank@wo​lfsonmicro.com> wrote on 11/08/2004
05:02:13 AM:

> 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 seems like the Synch view might make this easier? Also, if the commit
dialog contained the list of files being committed, as Tortoise does,
would that help? Or did you need to be able to access the content of the
source?


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

I agree this would be nice. I also struggle with that.

> - It would be nice to have the option of bringing the console to the
> front
> after all operations, not just errors.

Agreed.

> 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)

I do not use Externals, but these sound good. Perhaps a special folder
decorator for externals? I am not sure about some of the other stuff. I
would have to say that these sound like post 1.0 features.

Mark


____________________​____________________​____________________​_________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
____________________​____________________​____________________​_________________

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Mark Phippard <MarkP at softlanding dot com>
Full name Mark Phippard <MarkP at softlanding dot com>
Date 2004-11-08 06:18:27 PST
Message Panagiotis Korros <panagiotis.korro​s@gmail.com> wrote on 11/07/2004
02:49:15 PM:

> Some comments on this discussion
>
> 1. Conflict Editor
> Eclipse already has a compare/conflict editor. The editor we use to
> compare with BASE or remote can be made to work as a three way editor
> (like the cvs plugin) comparing local with remote using a common
> ancestor (BASE).

This could be used in the synch view, but if I just do an update and a
conflict is created in my working copy, could it be used then? I still
like the idea of adding a preference to launch an external program. As I
said, there could be a default of "built-in" once we have a way to do this
within Eclipse.

> 2. Merge
> We could port the merge synchronizer/participant from the CVS plugin
> and use svn merge -dry-run to populate the synchronizer. This would
> show a list of resources that need updating and will also show the
> conflicts.

That sounds good.

> 3. Update to Revision is in fact a 'Replace with revision' action in
> eclipse terms. I think we should keep the eclipse terminology.

First off, I checked before I wrote this, and did not see that option
available in my Subclipse projects. So I assume you are just suggesting
that is the way to implement this? Second, I am not sure I agree,
although I have never used this option in Tortoise. I assume this option
exists for a specific scenario. Say you are at revision 1000 in your WC
and have made a bunch of changes. You know that the HEAD revision (1050)
has some conflicting updates, but you need some non-conflicting updates
made by someone else in revision (1044). This option would let you bring
your WC to 1044. I just think Replace with seems unintuitivein this
scenario.

I wonder if Replace with might not be the way to approach the "Switch"
option however?

> 4. We could use the ecliplse 3.0 cvs images to make the subclipse
> icons to be consistent with the eclipse ui.

Fine with me. I am not using CVS anymore, last time I did, it did not use
many images. I personally, like having images on menu actions, but it is
not critical to me.

> 5. Subclipse currently is a mixture of eclipse 2.1 and Eclipse 3.0 CVS
> code. We should try to use the eclipse 3.0 api more.
> In particular the jobs api is a powerful tool to execute commands
> (operations) in the background by locking only the affected resources.
> A start has been made with the update action that uses the
> TeamOparation API. It locks the project that is being updated and
> allows the user to work on other projects.
> All lengthy subclipse actions should be backgroundable.

I think this would be great to have, but in my opinion, it is less
important than getting all the functionality nailed down. That being
said, this is open source and if this is an itch you want to scratch I do
not have any objections. I just think that Subclipse has been stagnating
a bit while working on these newer features. I think my document showed
that there are only a small number of core features that are missing. It
seems worthwhile to try to nail these down and then start making things
"better".

I would also like to see some of these core features backport to Eclipse
2.1 as the IBM WSAD base is not insignificant.

> 6. The sync view is a powerful tool. We use the svn status -u command
> to populate a tree with local and and a tree with remote changes.
>
> Implementing it for subclipse has many problems because the javahl
> bindings doesn't give anough information to populate it correctly.
>
> Problems:
> a. We don't know if a remotely added resource is a file or directory.
> b. We don't know the revision that a remote resource was changed.

Can't these things in JavaHL be fixed?

> Currently it not used because it is not complete. things to be done:
> 1. Add Commit, Update, Ignore, Add to version control
> actions to the sync view (these actions must implement the
> SynchronizeModelAction).
> 2. The sync view should be made to listen to the
> workspace modifications and update itself automatically (partially
> implemented and buggy).
> 3. Write unit tests
>
> I am working in the sync view but currently i lack the time to make it
> work. Any help would be appreciated.

How about you take ownership of the "Synchronize feature" and define the
work that needs to be done? Break it up into chunks and ask for
volunteers? For example, it seems like there are a number of people that
could probably tackle the actions, while you perhaps work on the core
synch parts? Just a thought. I think a lot of people know you are
working on this, and do not want to step on what you are doing. More
communucations might help move it along.

Mark




____________________​____________________​____________________​_________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
____________________​____________________​____________________​_________________

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Ian Brockbank <Ian dot Brockbank at wolfsonmicro dot com>
Full name Ian Brockbank <Ian dot Brockbank at wolfsonmicro dot com>
Date 2004-11-08 02:02:13 PST
Message 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 dot brockbank at wolfsonmicro dot com / apps at wolfsonmicro dot com
scd: ian at scottishdance dot net
t: +44 131 272 7145
f: +44 131 272 7001
  

 

> -----Original Message-----
> From: Mark Phippard [mailto:MarkP at softlanding dot com]
> Sent: 05 November 2004 17:04
> To: dev at subclipse dot tigris dot org; users at subclipse dot tigris dot 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.softl​anding.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.ne​t/repos/tortoisesvn/​trunk/doc/issuetrack​ers.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.ne​t/repos/tortoisesvn/​trunk/doc/issuetrack​ers.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.
> ____________________​____________________​____________________​__
> __________
>
>

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author David Corbin <dcorbin at machturtle dot com>
Full name David Corbin <dcorbin at machturtle dot com>
Date 2004-11-07 15:26:56 PST
Message Just a a few comments from the peanut gallery...

> 3. Update to Revision is in fact a 'Replace with revision' action in
> eclipse terms. I think we should keep the eclipse terminology.

Being consistent with Eclipse is a very good thing.

> 4. We could use the ecliplse 3.0 cvs images to make the subclipse
> icons to be consistent with the eclipse ui.

However, I do have a problem with being consistent here. Subclipse should
really have it's own identity, not look just like CVS. I noticed that the
perspective icon is NEARLY identical the CVS perspective. And, the resource
decorator looks exactly the same. This makes it very hard to distinguish
between the two. I don't have specific recommendations for what they SHOULD
be, but I think this icons should be diffierent. Icons that represent
actions that are common to many source control systems should however, be in
common between different team providers.

David Corbin

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author pkorros
Full name Panagiotis Korros
Date 2004-11-07 11:49:15 PST
Message Some comments on this discussion

1. Conflict Editor
Eclipse already has a compare/conflict editor. The editor we use to
compare with BASE or remote can be made to work as a three way editor
(like the cvs plugin) comparing local with remote using a common
ancestor (BASE).

2. Merge
We could port the merge synchronizer/participant from the CVS plugin
and use svn merge -dry-run to populate the synchronizer. This would
show a list of resources that need updating and will also show the
conflicts.

3. Update to Revision is in fact a 'Replace with revision' action in
eclipse terms. I think we should keep the eclipse terminology.

4. We could use the ecliplse 3.0 cvs images to make the subclipse
icons to be consistent with the eclipse ui.

5. Subclipse currently is a mixture of eclipse 2.1 and Eclipse 3.0 CVS
code. We should try to use the eclipse 3.0 api more.
In particular the jobs api is a powerful tool to execute commands
(operations) in the background by locking only the affected resources.
A start has been made with the update action that uses the
TeamOparation API. It locks the project that is being updated and
allows the user to work on other projects.
All lengthy subclipse actions should be backgroundable.

6. The sync view is a powerful tool. We use the svn status -u command
to populate a tree with local and and a tree with remote changes.

Implementing it for subclipse has many problems because the javahl
bindings doesn't give anough information to populate it correctly.

Problems:
a. We don't know if a remotely added resource is a file or directory.
b. We don't know the revision that a remote resource was changed.

Currently it not used because it is not complete. things to be done:
               1. Add Commit, Update, Ignore, Add to version control
actions to the sync view (these actions must implement the
SynchronizeModelAction).
               2. The sync view should be made to listen to the
workspace modifications and update itself automatically (partially
implemented and buggy).
               3. Write unit tests

I am working in the sync view but currently i lack the time to make it
work. Any help would be appreciated.

Korros Panagiotis

On Fri, 5 Nov 2004 20:38:07 -0500, Mark Phippard <markp at softlanding dot com> wrote:
> > I started a todo list based on your document
> >
> > http://subclipse.tig​ris.org/roadmap.html​
>
> Great.
>
> I kind of thought the lack of support for svn switch and svn merge were two
> of the biggest holes. I do not see them mentioned. Are they already
> supported and I am missing something, do you see them as being part of some
> other feature mentioned, do you just not agree, or did you just miss them?
>
> Mark
>
>
>
>
> ____________________​____________________​____________________​_________________
> Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
> ____________________​____________________​____________________​_________________
>
> --------------------​--------------------​--------------------​---------
> To unsubscribe, e-mail: users-unsubscribe@su​bclipse.tigris.org
> For additional commands, e-mail: users-help at subclipse dot tigris dot org
>
>


--
Take back the web http://www.getfirefox.com

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org

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

Author Mark Phippard <MarkP at softlanding dot com>
Full name Mark Phippard <MarkP at softlanding dot com>
Date 2004-11-05 17:38:07 PST
Message > I started a todo list based on your document
>
> http://subclipse.tig​ris.org/roadmap.html​

Great.

I kind of thought the lack of support for svn switch and svn merge were two
of the biggest holes. I do not see them mentioned. Are they already
supported and I am missing something, do you see them as being part of some
other feature mentioned, do you just not agree, or did you just miss them?

Mark


____________________​____________________​____________________​_________________
Scanned for SoftLanding Systems, Inc. by IBM Email Security Management Services powered by MessageLabs.
____________________​____________________​____________________​_________________

--------------------​--------------------​--------------------​---------
To unsubscribe, e-mail: dev-unsubscribe@subc​lipse.tigris.org
For additional commands, e-mail: dev-help at subclipse dot tigris dot org
Messages per page: