RE: [platform-vcm-dev] Team + Refactoring (cont.)

["Clemm, Geoff" <gclemm@xxxxxxxxxxxx>]

Thanks, Kevin, that all now makes sense.

Cheers,
Geoff

-----Original Message-----
From: Kevin McGuire [mailto:Kevin_McGuire@xxxxxxx]
Sent: Friday, June 21, 2002 4:48 PM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: RE: [platform-vcm-dev] Team + Refactoring (cont.)



The delta notification is a Core mechanism which any plugin can listen and
react to.  It supercedes move/rename/delete as namespace notification
operations.  It is used throughout eclipse to do things like update the
tree views in the UI, etc.  So the detlas aren't just about content - they
are a general mechanism to notify of resource changes (content or
structural).

Move/rename/delete by contrast is a Team specific mechanism which provides
control over the actual operations.  Think of the later as equivalent to
"you the provider getting to implement IResource.move(), IResource.delete
()".  Only providers get to do it.

If you're a provider who supports namespaces but don't have locking, deltas
are likely sufficient.  If you support some kind of locking, then you need
move/rename/delete so you maintain integrity, ensuring that the workspace
reflects the repository state should a lock/checkout fail.

Kevin





 

                      "Clemm, Geoff"

                      <gclemm@xxxxxxxxxxxx>           To:
"'platform-vcm-dev@xxxxxxxxxxx'"                     
                      Sent by:
<platform-vcm-dev@xxxxxxxxxxx>                                
                      platform-vcm-dev-admin@         cc:

                      eclipse.org                     Subject: RE:
[platform-vcm-dev] Team + Refactoring (cont.)    
 

 

                      06/21/2002 04:19 PM

                      Please respond to

                      platform-vcm-dev

 

 




The first part of Kevin's explanation made sense to me,
i.e. ValidateEdit is only for content changes, and therefore
is not called on rename/move/delete, but is called if the
rename/move resulted in a content change, at which time
ValidateEdit should be invoked.  (I.e. if ValidateEdit is
being called on rename/move/delete, it should be called
on the folders involved, but not calling it at all on rename/
move/delete is fine).

The second part of the explanation did raise a question ...
the move/rename/delete hook certainly is the right place to
handle move/rename/delete processing.  But why is "delta notification"
relevant here, since delta's are about content, and
rename/move/delete are namespace operations, not content
operations?

Cheers,
Geoff



-----Original Message-----
From: Kevin McGuire [mailto:Kevin_McGuire@xxxxxxx]
Sent: Friday, June 21, 2002 3:12 PM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: RE: [platform-vcm-dev] Team + Refactoring (cont.)



No, this isn't a bug:

ValidateEdit() is unrelated to namespace operations.  Its only called when
content changes are about to occur.  I believe what's happening in the case
cited is that when you rename a Java file, Java refactoring kicks in and
renames the class declaration to match the filename.  Thus you are getting
the validateEdit() notification from the Java refactoring engine who is
being a good citizen.  The context is null presumably because they don't
have access to the shell at the point in their code where they need to call
validateEdit().

You can't rely on validateEdit() for rename/move/delete -- if you do the
same steps with a non-java file you won't get notified via this.  You can
find out about move/rename/delete either via delta notification, or via the
move/rename/delete hook in the provider (depending on whether you require
veto or extra work to occur).

If this doesn't match what you are seeing let me know.

Cheers,
Kevin







                      "Clemm, Geoff"

                      <gclemm@xxxxxxxxxxxx>           To:
platform-vcm-dev@xxxxxxxxxxx
                      Sent by:                        cc:

                      platform-vcm-dev-admin@         Subject: RE:
[platform-vcm-dev] Team + Refactoring (cont.)
                      eclipse.org





                      06/20/2002 11:29 PM

                      Please respond to

                      platform-vcm-dev








This is a significant bug.  A move/rename is not a modification
to the file being moved, it is a modification to the directory/folder
that originally contained the file, and a modification to the
directory/folder that will contain the file.

So MOVE(/a/b, /c/d) should result in an IFileModification to
/a and an IFileModification to /b, not to /a/b or to /c/d.

Similarly, a DELETE(/a/b) should result in an IFileModification
to /a, not to /a/b.

On the other hand, a COPY(/a/b, /c/d) should result in an
IFileModification to /c/d.

Cheers,
Geoff

-----Original Message-----
From: David Corbin [mailto:dcorbin@xxxxxxxx]
Sent: Thursday, June 20, 2002 6:44 PM
To: platform-vcm-dev@xxxxxxxxxxx
Subject: [platform-vcm-dev] Team + Refactoring (cont.)


When a Java file is renamed, I'm getting a call to
IFileModification.validateEdit with a null context.  This is problematic
for us.  We really need to know that it is being moved before it is
being edited.

I'm not (personally) familiary with IFileModification, but is there any
way for us get the move first before the edit attempt, or for the
validateEdit to provide context that tells us this is being called as
apart of a rename/move?

_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev




_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev