Bugzilla – Full Text Bug Listing
| Summary: | IResource#getModificationStamp() could be more useful after resource delete / re-create | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | James Blackburn <jamesblackburn+eclipse> | ||||||
| Component: | Resources | Assignee: | Platform-Resources-Inbox <platform-resources-inbox> | ||||||
| Status: | RESOLVED DUPLICATE | QA Contact: | |||||||
| Severity: | normal | ||||||||
| Priority: | P3 | ||||||||
| Version: | 3.6 | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| Bug Depends on: | |||||||||
| Bug Blocks: | 311189 | ||||||||
| Attachments: |
|
||||||||
Created attachment 167949 [details]
test + proposed fix
I tried a number of different fixes. But ultimately the easiest seems to be to start the modTime from something other than 0 (System.currentTimeMillis() seems like a good start).
The result is that, for users of this API, it's now very unlikely for #getModificationStamp() won't change when the resource has changed in the workspace tree.
Trivial fix + test. All other tests look good.
Duplicate *** This bug has been marked as a duplicate of bug 160728 *** |
Created attachment 167927 [details] test 1 IResource#getModificationStamp() states: * A resource's modification stamp gets updated each time a resource is modified. * If a resource's modification stamp is the same, the resource has not changed. * Conversely, if a resource's modification stamp is different, some aspect of it * (other than properties) has been modified at least once (possibly several times). Unfortunately this isn't quite true. What actually happens is that: resources which don't exist have a modificationStamp of NULL_STAMP(-1), and on creation and at every modification operation this is incremented. The problem I've got is that I took #getModificationStamp() at its word. I expect the returned value to be different if the resource in the resource tree is different from when I last asked. Unfortunately, in a relatively simple test, I find it's not: - Checkout a project set from some SVN revision number - Update project set to head - Checkout again, replacing existing resources. The issue is that while the SVN team provider deletes and replaces my project metadata (in a single workspace operation), at the end of the second checkout the modificationStamp is the same as it was before == 1. The API description of the modification stamp is flexible, unless it's NULL_STAMP, it's a non-negative number. Clients should treat any change as if the resource has changed. If, on creation, we primed the modification stamp with ResourceInfo#localInfo (which, handily, corresponds to the real filestore modification time) this would resolve the issue of all modification stamps starting from 0, even for different resource generations. Test attached.