When morpho saves a network data package to local, the system metadata may contain id (obsoletes) which doesn't exist
Here are the steps to produce the bug:
1. Create a data package with data object and save it to the network. It contains:
resourceMap_foo.1, foo.1 and data.1
2. Update data.1 and save it to both network and local. It contains resourceMap-foo.2, foo.2 and data.2.
When we check the metadata for the resourceMap_foo.2, we found it has the <obsoletes>resourceMap_foo.1</obsoletes>. Actually the local doesn't have resourceMap_foo.1.
Same thing to the foo.2 and data.2.
Updated by ben leinfelder almost 11 years ago
This is tricky. I know we decided a while back that we should manage the revision history separately for local vs. network objects, but in the old days when we used scope.docid.rev we implicitly considered revisions across their locations (so a newer version on the network does actually obsolete an older version locally even if it isn't yet saved locally).
I think we might have to manage revisions centrally so that we allow something on the network to obsolete something locally (and the other way around). There's another bug that might be related to this involving the search results: #5805
Updated by ben leinfelder over 10 years ago
Jing and I talked about a related issue today and decided that we CAN leave the <obsoletes> values in local system metadata so that the revision chain does not get broken if we save a network file locally as a new revision and then save it back to the network after making multiple revisions locally.