Community
Participate
Working Groups
With the new universal undo concept in Platform/UI the demand grows for a content stamp model to check if a undo object is still valid. Consider the following case: - a refactoring gets executed with produces a undo object - another undoable operation gets execute which tocuhes the same files as refactoring did. - the operation gets undo - the refactoring operations gets undo However, the refactoring operations refuses the undo since the state of the files its going to revert has changed (e.g both the timestamp and the modification steps got incremented). However from a content point of view the refactoring could be undone. To solve this problem refactoring internally introduced the notation of a content stamp (see class ContentStamp). For a more general undo solution something comparable must be provided by core resources. Either a new attribute content stamp or a settable modification stamp.
John, as discussed with Nick I will assign the PR to you.
Here are my words from the email discussion: <I mentioned> the requirement to be able to reset a resource's modification stamp (not its time stamp) to a previous value, in order to support validation of resource-based undo operations (generalizing beyond what the refactoring support currently does). It may suffice to just provide a void setModificationStamp(long stamp) method on IResource, although we'd need to be sure that the criteria for things that affect the modification stamp (as spelled out in the Javadoc) are not violated by allowing this. For example, if operation OP changes the contents of resource R, and causes the CVS support to set a property on R indicating that R is dirty, then OP is undone, is it OK to reset the modification stamp even if there was a change to one of its properties? (I'm assuming that undoing OP will not roll back CVS's dirty flag)
It sounds like setModificationStamp(long) will do the trick. The current specification of the modification stamp is sufficiently vague that clients shouldn't be affected as long as the client setting the modification stamp ensures that the reverted stamp matches the old contents of the file. The current spec explicitly says the sign or magnitude of a modification stamp change is meaningless, so moving either back or forward will look the same for most clients. We don't use the modification stamp in delta computation, so rolling back a modification stamp in the same operation in which it changed will not cause the delta to be empty. The only downside is that we currently store the modification stamp internally packed into a rolling two byte counter (a long value was overkill in the design). Allowing setting an arbitrary long value would require us to store eight bytes, an increase of six bytes to the overhead of each resource in memory. One possibility is that we call it undoModificationStamp(long), and require that they assign a value that was previously a valid modification stamp. We could then safely store the value back into our two byte field.
Dirk, does it look to you that something like IResource.setModificationStamp would satisfy your needs? Based on what I see in ContentStamp it looks like it will do the trick.
Yes, having a settable modification stamp will do the trick.
Released new API method, IResource#revertModificationStamp(long). I preferred "revert" over "set" to make it clear that this is a specialized usage for undo and not a simple setter. Tests added to IResourceTest#testRevertModificationStamp.
Opened bug 86135 to make use of the new API.
