Community
Participate
Working Groups
VCM needs a Core-supported way of getting / setting the file's modification stamp in order to be compatible with the CVS command-line client's mechanism for determining if files are dirty (have been changed since last checkout). Current workaround is to obtain an instance of a java.io.File and use lastModified() / setLastModified(). In the case of setLastModified() we follow-up the request with a refreshLocal to avoid resource out of sync errors.
Using java.io.File for this is probably the right solution. The timestamp that we store is not necessarily the same as the one on disk.
By changing the modification stamp on disk ourselves, we potentially make the resource tree out-of-sync since the modification stamp is derived from the timestamp on disk. The idiom ends up being something like: setLastModified(...) refreshLocal(... IResource.DEPTH_ZERO) actualTime = lastModified(...) A core-supported mechanism could perhaps handle this more efficiently, or at the very least eliminate the refreshLocal.
*** Bug 16551 has been marked as a duplicate of this bug. ***
Deferring until post 2.0. Will investigate then to see if this is still necessary.
Reopening for consideration.
Adding KM to CC list. Is this still a requirement?
Yes! There are two issues: 1- Going through the java.io.File API, then forcing refreshFromLocal, is expensive. My understanding is that Core has a faster mechanism for setting file timestamps. 2- Going through java.io.File to get the timestamp is expensive, and feels needless since I believe Core caches one. We do this extensively to determine dirty state for decorators and spend a considerable amount of decorator time doing so. Re, John's comments >>The timestamp that we store is not necessarily the same as the one on disk. I don't understand why this is. Note that the modification indicator on IFile is weak and basically of no use to VCM since it doesn't answer our question "Is this file the same as the one we got?". We need: - a way to set the time on the file when we get it from the server - a way to compare the current file time with the one stored - accomodate external modification of files, and use of the CVS command line
I've just profiled the CVS plugin and again noticed that the get/set timestamp methods are slowing down most CVS operations. Especially the fact that we have to perform a refreshLocal() after calling java.io.File.setLastModified(). Could this be considered for 3.0?
Done. Added and released methods IResource.getLocalTimeStamp and IResource.setLocalTimeStamp. Please let me know if this API is sufficient.
