Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [platform-team-dev] Fwd: movedeletehook


McClain,

The implementor of the move/delete hook gets to decide how a move takes place. For CVS what we do is move everything and then walk the new tree to remove the moved CVS folders since they are not relevant in the new location. Another option is to perform the move "manually" in the file system and then inform the IResourceTree that is provided to the move/delete hook that a custom move has been completed (using IResourceTree#movedFolderSubtree).

As for the timing of the move, all moves are done through the move delete hook so you should always get to decide how the move takes place. If this is not the case, then this is a bug.

Michael



McClain Looney <mlooney@xxxxxxxxx>
Sent by: platform-team-dev-admin@xxxxxxxxxxx

19/09/2004 11:41 AM

Please respond to
platform-team-dev

To
platform-team-dev@xxxxxxxxxxx
cc
Subject
[platform-team-dev] Fwd: movedeletehook





I previously sent this from an unsubscribed address...


---------- Forwarded message ----------
From: McClain Looney <mlooney@xxxxxxxxx>
Date: Wed, 15 Sep 2004 21:27:58 -0500
Subject: movedeletehook
To: platform-team-dev@xxxxxxxxxxx

Hi,

I'm working on a team plugin, and am having some difficulty with the
movedeletehook. It seems that during a java package refactor, the
movedeletehook is trying to move the team metadata directories (CVS or
.svn for example). This causes a problem, since the metadata directory
is already created by a prior move operation by the actual provider
implementation (svn mv on a directory will create a new .svn directory
in the target directory, since the new directory is immediately
scheduled for repository add). Moving the source .svn folder is not
desirable anyway, since it's invalid at the new location. This of
course violates the contract of the movedeletehook, since it
guarantees that the target folder should not exist when the hook is
invoked.

Are we misusing the movedeletehook api? Or is this a shortcoming of
the api itself?

The error manifests with a "error moving files" message, stating that
"x/y/z/.svn already exists." This occurs before entry into our hook
method, so we can't just short-circuit the move ourselves.

If you'd like to see our implementation, it's available in our svn
repository at http://svn.collab.net/repos/subclipse/branches/subclipse-3/core/src/org/tigris/subversion/subclipse/core/resources/SVNMoveDeleteHook.java

Regards,

--
McClain Looney
m@xxxxxxxxxxxx




--
McClain Looney
m@xxxxxxxxxxxx
_______________________________________________
platform-team-dev mailing list
platform-team-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-team-dev


Back to the top