Mark Phippard wrote:
>> Mark, nothing personal, but can you explain how is possible that pending view is "much faster" then Synchronize view if they both going against the same data structures?
>>
>>
> I appreciate that you show in an interest in this project and that you take
> the time to report bugs and even submit patches for features and bugs. Not
> a lot of people bother to do that, but you do. So thanks. But yes, I do
> get pissed off and take it personally when you repeatedly toss in this
> backhanded snipes. Especially the implication that this is all easy and we
> just choose not to make it work the way you want.
>
I didn't say it is easy. But I wanted to point out that it should be
fixed at some point. I am pissed off as much as you are if not more that
project going really slow in this area.
There also newcomers that had have no experience with Eclipse and
ready to use whatever existed they find first even if it is less efficient.
> As to your question ... I am not the one that brought this up or made those
> comments, I believe it was Dan North. However, you already gave the
> answer. The Pending Ops view is faster because it only shows outgoing
> information. It is purely a local operation.
>
Well, if you think from the UI point of view this is as local as
Synchronize view in outgoing-only mode.
I probably should also point out that Sync view can show more then
single subfolder at once and provide much better flexibility up there.
> If you recall, I am the one that has raised the issue in the past as to
> whether the Pending Ops view is obsolete and should be removed. Enough
> people have responded that I would not consider it anymore. That being
> said, I agree with you that people that want to see this sort of
> information probably ought to use the Synchronize view. I think it is safe
> to say that if this project had not started before the Synch framework
> existed, that we probably would not have a pending ops view.
>
> Let me also explain why I am currently working on this view.
>
> I recently made a change to Subclipse to add a feature that I needed. I
> support an IBM tool that generates JSP and XML files (that are versioned)
> by deleting and recreating the file. Subclipse sees the delete and issues
> an svn delete. Therefore, the change is not treated as a modification. So
> I added support for a SVN property you can set named "DeferFileDelete".
> When this is set to true, then Subclipse will just let Eclipse delete the
> file without running svn delete. Problem solved.
>
> Since I was making a change like this, I thought it was a good time to
> improve the Subclipse handling of "missing files". These are files that
> Subversion thinks should be in your WC but are not.
>
> The first change I committed was one that TortoiseSVN has. The commit
> dialog now show missings items (deselected). If you select them and
> commit, we run svn delete and then commit them. Basically the same thing
> we do for unversioned files and adds.
>
> The Synch view has problems though. It shows missing files as incoming
> changes (I think this might be what you are seeing with Maven synchs). I
> am not going to try to fix this, maybe Martin will someday? What I needed
> was a way to flag the item as deleted (which is harder than it sounds since
> the file does not exist). So I decided to start showing missing items in
> the Pending Ops view and add an option there to mark it as deleted (or
> revert). I have this mostly working but there is some flakiness I still
> need to fix. Once the file is marked as deleted, the Synch view then works
> correctly.
>
I see your points but still begging to think about investing some time
to clean up sync view. That would be a much better investment for a long
term.
regards,
Eugene
Received on Fri Nov 25 13:48:59 2005