On Tue, Jan 08, 2013 at 09:20:13AM -0500, Mark Phippard wrote:
> On Tue, Jan 8, 2013 at 8:57 AM, Stefan Sperling <stsp_at_apache.org> wrote:
> > Can't the intercepting code decide to ask the user to update a subtree
> > before refactoring it?
>
> The best answer I can give right now is "I do not think so".
> Generally the SCM plugins register callbacks that the IDE calls when
> it wants to. It is possible there are some non-SCM specific callbacks
> for refactoring pre-checks. I would have to look. I know they are
> not part of the SCM API.
>
> Keep in mind that with tree structure changes, the user action is
> often something like a drag and drop. So the ability to get involved
> before this happens is fairly impossible. The dialog-based
> refactorings would be the more likely place where something could be
> done.
I'm not sure I understand what the real issue is here.
So the user drags+drops, thereby triggering an 'svn mv' call.
If the subtree being dragged and dropped is mixed-revision, Subversion
will raise an error asking the user to update the subtree first and
then try again.
How is that any different to the case where the user runs 'svn mv'
manually and gets the same error?
The UI to trigger the move is different. But I don't see how that
would seriously prevent IDEs from supporting move-tracking.
In case the IDE has already modified the on-disk state without telling
Subversion about it, the IDE should of course undo the move on disk if
the Subversion move fails. But that has always been the case. If an IDE
doesn't do that today, it is already buggy.
Received on 2013-01-08 16:10:29 CET