Having to manually deal with resync of overrides is a growing problem in production context. Further more, not all possible cases are yet covered by current resync code.
We have to find a way to detect all cases where a resync is needed. Then either warn user about it, or do it as a new, automatic step after .blend file has been read?
Here is a list of cases (changes in library data) that affect ID pointers:
Note: Status reflects current code in override-refactor-tmp branch, not yet in master.
Step I
1) New ID
A new ID is added in the hierarchy/dependency chain of linked data that is already overridden, and that new ID should also be overridden (because e.g. it has dependencies over already overridden IDs). Or an existing linked ID starts using another one that is overridden, and therefor would also need to become overridden.
Detection
- This can be easily detected using same code we currently use to re-sync/rebuild the overrides.
Handling
- Current re-sync code is already working fine in that case.
2) ID re-assignment - Already Overridden
An ID usage in the hierarchy/dependency chain of linked data that is already overridden, gets re-assigned to a different ID that is also already overridden.
Detection
- This needs some minimal extra/new work in override properties, to tag operations over ID pointer properties as 'matching' original linked data, or not, when generating override operations. We can then detect a mismatch when applying those rules (on file loading e.g.).
Handling
- Current re-sync code is already working fine in that case.
3) ID re-assignment - Not Yet Overridden
An ID usage in the hierarchy/dependency chain of linked data that is already overridden, gets re-assigned to a different ID that would now need to be overridden.
Detection
- Same case as 2) above.
Handling
- Will require a full resync, not always properly handled by current resync code (when the previous assigned ID remains a valid one with an existing override).
4) ID unassignment
An ID usage in the hierarchy/dependency chain of linked data that is already overridden, gets unassigned.
Detection
- Same case as 2) above.
Handling
- Current re-sync code is already working fine in that case.
5) Removed ID
A currently overridden ID in the hierarchy/dependency chain of linked data that is already overridden, gets deleted (or not used anymore) in the linked data.
Note that this is close to 4) unassignment case above, but we may also need to clear the overrides of the removed ID? Although regular 'not used anymore' cleanup process on save & reload should also do the trick here.
Detection
- Same case as 2) above.
Handling
- Current re-sync code is already working fine in that case.
Step II
Report detected 'need resync' cases in UI, and/or perform needed resync automatically.
The later solution would be ideal, however it is not yet clear how heavy that process will be (and hence how much time it would add to loading production .blend files).
- Try to only re-override needed IDs (in theory partial re-sync of only affected IDs should be doable?).
- Add post-loading step to re-generate needed overrides.