Re: [Subclipse-users] "Override and update" from conflicts view

On 8/15/07, Zach Bailey <zach.bailey@hannonhill.com> wrote:
> I just had a frustrating behavior bite me...
>
> I did the following:
>
> 1.) Sync'd and saw I had some conflicts on about 10 files
> 2.) Instead of selecting each file individually, I selected the project
> root in the synchronizing view and did "override and update" expecting
> it to only override and update the CONFLICTS since I was in the conflict
> view rather than overridding and updating the
> whole project. Unfortunately this proceeded to wipe out a rather large
> amount of work I had done over the past couple of days.
> 3.) I tried restoring changes from the local history and found I could
> only restore "new" files that had not yet been added to the repository.
> Changes on existing, versioned files were completely wiped out and the
> local history was completely wiped out too
> (http://subclipse.tigris.org/issues/show_bug.cgi?id=575).
>
> I am now facing the fact that I have to re-write a significant portion
> of some work I've been doing over the past 2 days, which is very
> frustrating.
>
> I have already commented/voted on issue 575 which convers maintaining
> local history, and I encourage other people to do so as well.
>
> My question is regarding the default behavior of the conflicts view in
> the synchronize view. If I select the project root in that view and do
> override and update, my intuition tells me that/I am expecting that
> subclipse will only override and update the items that appear in that
> view, which is similar to the other views. For example if I remove a
> file from the "outgoing" view and then select to commit the project root
> from that view, I expect the file I removed not to show up.
>
> Am I off base here, or is this just an oversight in the module that
> handles this view action?

I'd say neither. Your expectations are reasonable, but there has been
no attempt to code the view to work the way you describe. In addition
it can be difficult in some cases to get the Subversion API's to
behave the way you are expecting.

Votes are irrelevant. No one is deciding what to do based on how many
votes are attached to an issue. What is needed is code and patches.
This issue is a good example. Attempts were made to make it work, the
right Eclipse API's do not seem to be exist. In this case, I suspect
someone with the right perseverance could probably make use of the
Eclipse API's that do exist to get it to work.

You should open a separate issue about the Synch view though. There
are really two issues here. The one you commented on is one of them,
ideally anything that was reverted would still show up in the local
history. The expected behavior of this action in the synch view is
another. I expect Override and update, to revert files with local
changes and then do an update. You raise a valid point though about
if the user is filtering by conflicts whether it should only process
the files that are currently shown.

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org