Description James Blackburn 2010-05-11 10:12:29 EDT

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.