[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [platform-vcm-dev] Re: Copy Listener
|
Good point, I had just assumed he had rejected the synchronizer for other
reasons.
One thing to note: in Team we use persistent properties because there are
UI filtering rules which can be triggered based on them. Don't know if
this is one of Joseph's requirements (sounds like not).
Kevin
"John Arthorne"
<John_Arthorne@xxxxxxx> To: platform-vcm-dev@xxxxxxxxxxx
Sent by: cc:
platform-vcm-dev-admin@ Subject: [platform-vcm-dev] Re: Copy Listener
eclipse.org
01/11/2002 11:51 AM
Please respond to
platform-vcm-dev
I should add one final point about sync info: changes to sync info are
recorded and reported in resource deltas (IResourceDelta.SYNC), which is
not the case for persistent properties. This can be very useful, for
example, in maintaing label decorators based on sync information.
----- Forwarded by John Arthorne/OTT/OTI on 11/01/2002 11:52 AM -----
John Arthorne
To:
platform-vcm-dev@xxxxxxxxxxx
11/01/2002 11:41 cc:
AM Subject: Re: Copy
Listener(Document link: John Arthorne)
Joseph, I am wondering if you considered using the special synchronization
information support in the workspace API. In addition to persistent
properties, each resource can have arbitrary "sync info" associated with
it. From your description, it seems like you should be using sync info
instead of persistent properties to store this information. Sync info has
some important properties that differentiate it from normal properties:
* Better performance - sync info is kept in memory, and only saved to disk
on workspace save and snapshot. Persistent properties may be written to
disk immediately so the performance can be much worse (although there is
some caching in memory).
* Sync info is *not* transferred over when a resource is copied. It is
carried over when a resource is moved, but not on copy.
* When a resource that contains sync info is deleted, the resource is kept
in memory as a "phantom" resource. That way you don't lose your sync info
when a resource gets deleted.
* Sync info support includes methods for visiting all sync info in a
subtree, and for flushing the sync info for a subtree.
The API for sync info is found on org.eclipse.core.resources.ISynchronizer,
accesible via IWorkspace.getSynchronizer().
John
-------
platform-vcm-dev-request@
eclipse.org To:
platform-vcm-dev@xxxxxxxxxxx
Sent by: cc:
platform-vcm-dev-admin@ec Subject:
platform-vcm-dev digest, Vol 1 #173 - 6 msgs
lipse.org
11/01/2002 08:30 AM
Please respond to
platform-vcm-dev
Message: 1
Subject: RE: [platform-vcm-dev] Copy Listener
Date: Thu, 31 Oct 2002 13:54:15 -0500
From: "Zulli, Joseph" <Joseph.Zulli@xxxxxx>
To: <platform-vcm-dev@xxxxxxxxxxx>
Reply-To: platform-vcm-dev@xxxxxxxxxxx
Hi Kevin,
Thanks for the response to my email. Here is my requirement. I wasn't
sure if you wanted me to email you or if you wanted me to append it to
the bug report. Let me know if you want the latter.
I am implementing a Team provider that has very advanced synchronization
features. A lot of the synchronization is made possible by using the
IResource.setPersistentProperty() method to assign each resource a
unique synchronization ID. So far, it seems that everything is working
very well except in the instance of copy. This is because when a file is
copied and pasted it's persistent properties are pasted with it. In my
case this is bad because I now have two different files with the same
sync ID, which causes all sorts of problems. The pasted file needs to
have it's sync ID removed and replaced with a different one. This is
easy to do as long as I can be notified of the copy/paste action taking
place. Using the IResourceChangeListener only tells me that the file is
added, which isn't enough information. For me, I think simply adding
copy to IMoveDeleteHook, or something similar would be good enough.
Modifying IResourceChangeListener to have a PASTED delta event would be
even cooler.
That's about it. Let me know if you need more info.
_______________________________________________
platform-vcm-dev mailing list
platform-vcm-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/platform-vcm-dev
