Re: [platform-team-dev] Fwd: movedeletehook

[McClain Looney <mlooney@xxxxxxxxx>]

----- Original Message -----
From: Michael Valenta <michael_valenta@xxxxxxxxxx>
Date: Mon, 20 Sep 2004 09:25:27 -0400
Subject: Re: [platform-team-dev] Fwd: movedeletehook
To: platform-team-dev@xxxxxxxxxxx

 
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).

> Our issue is that the hooks are trying to move the metadata dirs, which are obsoleted (new ones already exist) by a previous move operation. At some point prior to the hook execution, the eclipse resource move stuff sees that the "target" .svn dir already exists and aborts _before_ the hook is entered.  

Your CVS case of walking the new tree and removing metadata is invalid
for our case, as the metadata directories in the target dir are
actually correct and valid. Our SCCM implementation understands move
and copy natively (horrors!).

Consider a dir like this:

src/.svn/
src/y.java
src/x.java

When the hook is executed to refactor package "src" to "target", a new
and correct .svn metadata dir "target/.svn" is  already created by our
hook (since our sccm impl is clever  enough to handle this). After
this, it appears Eclipse is invoking our hook to move src/.svn to
target/.svn , and blowing up since the previous operation already
created target/.svn, inadvertantly creating a valid situation which 
violates the hook contract requiring the target to not exist when the
hook is invoked.

The exception occurs _before_ our hook can short-circuit it.  What we
really want to do is say "for moveFolder x, totally ignore it's child
.svn dir, and let us handle the move. don't even recurse into it, we
have it covered."

Does this clarify anything (besides my density)?

-- 
McClain Looney
m@xxxxxxxxxxxx