Mario, You understand this subject well, provided elegant documentation in the related topics. Thanks very much.
- I truly understand the issues you raise, and we have discussed in the past.
- Here I carefully spell it out to maintain simplicity of my argument.
I would like to add a little additional nuance and discuss a very simple dif and merge, one which users/designers may make use of and may one day be applicable in the upgrade process.
- If more than one shadow/plugin contains the same tiddler, all bets are off and it is something we should avoid.
- I am only interested in the difference between a shadow and its edited tiddler. These are the two tiddlers, you have documented this nicely here
- I am not talking about patch management, distributing patches or anything else, just the ability to identify and capture differences when a shadow has being modified, at an all fields level.
As you know when we edit a shadow tiddler, typically the modified and modifier and/or created creator fields most likely change. If that is all that changes most likely one could just delete the tiddler and restore that shadow.
- A simple programmatic way, eg a macro or better a filter operator, to detect an edited tiddler with no “effective difference” would be helpful. This would help list and delete tiddlers that are unnecessarily edited tiddlers, This is an all fields check, excluding nominated fields, at present it is only the text field using manual preview diffs.
There are however a number of legitimate reasons to edit a shadow tiddler, changing the text or any other field. But there is an issue when an upgrade to the underlying core or plugin occurs, in so much as the edited tiddler remains in force while the underlying tiddler has changed.
- it is important to acknowledge this status quo is not perfect.
- these changes are in fact trivial 90% of the time like;
- “show” instead of “hide”,
- or insertion of a key/value pair in a create tiddler widget etc…
- or adding / removing a tag/field or value etc…
My thought is, what if we could run a process to save the differences between shadows and tiddler to a data tiddler (or otherwise) and allow us to restore the shadow, we would then have a record of the edits. This would then allow a batch or manual reapplication of the saved changes later?
- We may retain both the original shadow and the edited shadow in this process, ensuring no information is lost.
- After a successful upgrade we can inform the wiki owner the following shadow edits were stored and they should reapply them only if necessary.
Thus the upgrade process could just save the differences (with a warning perhaps) clear the over written tiddlers and upgrade the wiki and or plugins. Then let the user or plugin selectively reapply the difference if need be.
- With such a process any “modified shadows” will become obvious, as they will have a differences record.
- The upgrade will be applied, reliably and all new features present
- It would be easy to “restore customisations” if needed/wanted.
Most importantly such a set of tools could be used on demand for troubleshooting or at upgrade time, They have nothing to do with the upgrade process except perhaps making it more reliable by letting all upgrades apply, and is only an issue at upgrade time. It is merely about being able to manage edited shadows at a moment in time.
- These tools would be useful even if not associated with the upgrade mechanism.
Finally if the same method could be used against other tiddler pairs like a new tiddler and its tiddler-source, previous versions etc… additional features could be build on top of tiddlywiki for change management and other solutions.