In SMTK, each Resource and Component is giving an UUID to uniquely identify the Resource or Component regardless of where it is located. However, we do have the issue of how to deal with the case where the Resource or its Components are modified.
For example, if there is an Attribute Resource referencing a Model Resource and later on that Model Resource is modified without the Attribute Resource loaded in memory. How do we detected that information migration may need to be performed?
Perhaps the user made a copy of the Model Resource file (which wouldn’t change the Resource’s UUID) and then modified that file. In this case, the existing Attribute Resource would be fine with the original Model Resource but may have a problem with the modified version.
What is needed is a way to version a Resource (and Component) in order to help identify modified objects.
Representing Versions
A naive way to represent versioning would be to use something simple like an unsigned int; however, the would not solve anything. Consider the above example where the user copied the Resource file. If the initial version was set to 0 and then both files were modified, then both would increment their versions to 1. As you can see, this would result in ambiguity in terms of what represents version 1 of the Resource.
Instead we could use a second UUID. When the version of a SMTK Persistent Object needs to be changed, the version would be assigned a new UUID. You can see that this would solve the above use case since each file would have the same Resource UUID but different Version UUIDs.
When another Resource references a Resource or Component it would record both its ID and Version in the Resource Link (instead of just its ID).
Version-based Changes
Supporting Version Information
Besides the UUID of the Version, we may want to store the following information:
- Alternative Version Name - this would be more readable though it can not be guaranteed to be unique
- Version Note - a string describing why the version was created and what it represents.
One possible way of dealing with versioning would be to clear the Version field when the Resource and/or Component is modified and then on saving set it to a new UUID.
Resource Link Changes
Both the ID and Version would need to be stored in the Link Information.
Resource Manager
In SMTK 23.01, if you attempt to load in a Resource with a UUID that is already in the Manager, the request will be ignored. This means that even if you had 2 different versions of a Resource, only one will ever get loaded. In the propose system, both the ID and Version will be referenced in the Manager so that multiple version can be loaded into the system.
Descriptive Phrase Changes
We may now need to group the various versions of a Resource in the Resource Browser.
Maintaining Version History
One issue with this approach is going to be trying to maintain some sort of history between Resource versions. For example a common query a user may have is how are 2 versions of a Resource related? Or in the case of a Resource associated with another, is a different Version of a Resource based on the one that was originally associated with another?
The Version history could be a simple list of Version UUIDs that would be saved inside the Resource’s smtk file. We could then provide a set of query/comparison functions.
Note that this would work for Resource Versioning but not if we wanted to maintain Component Version. To do that we would have to maintain for each Resource Version, a list of Component ID,Version pairs.
A Component change list could be helpful when migrating information from one Resource Version to another. One main issue would be how this could be managed when the Resource has thousands of Components.