[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: SVN conflict decorator/markers -- more

From: Brock Janiczak <brockj_eclipse_at_ihug.com.au>
Date: 2005-03-09 11:14:53 CET

Mark Phippard wrote:

>I was thinking about that too, as it would let you do all of the actions
>from the Problems view, and not have to expand folders etc... My concern
>was that someone would Resolve without removing the markers. Are you
>suggesting that we make the three options be:
>Edit Conflicts
>Accept Yours/Base --> This would just run Revert and Resolve?
>Accept Mine/Local --> This would need to copy the .mine and Resolve?
>Or are you suggesting we just have the 3 options be:
>Edit Conflict
>Mark Resolved
>And the user might run Quick Fix multiple times to take the appropriate
I was suggesting the second one (quick fixes that run either revert,
resolve or edit conflicts), but I forgot that SVN automatically merged
the files for you :)
So, the first first option you suggested would be the way to go. It
might be good to have a resolve action too if the user has manually
fixed the errors (they can alwyas use the team context menu too).

If you want, i could knock them up on the weekend.

>It would be nice if Edit Conflicts had a way to let you run Resolve as
>part of saving the way that TortoiseMerge does.
This could be hooked up in ConflictsCompareEditorInput. The problem is
that the editor may have to be closed (or closing) when the resolve
happens. I will need to try this out...

>>I am not sure the decorator is the best place to be deleting and
>>creating the markers. We could remove the markers in the
>>revert/resolve/edit conflict operations and possibly create them using
>>the notify handler (not too sure about this though).
>I wasn't sure about it either, but it does seem to work. The decorators
>seemed like the only place we could realistically set the marker, so it
>made sense that it be the place that removes it as well. It also handles
>the case where the conflict is resolved using an external tool/process
>that Eclipse would not capture. Feel free to look at ways to improve it!
We do pick up changes to the .svn files though a resource listener
(requires the folders to be refreshed) so it should be possible to catch
the new conflicted statuses with the notify listener. It might even be
possible to hook it into the Sync info...
If i get a chance, i will look at alternatives, but your scheme does
work, so I am not too worried.
Received on Wed Mar 9 21:14:53 2005

This is an archived mail posted to the Subclipse Dev mailing list.