Community
Participate
Working Groups
If errors occur during externalization the task list can break. Also need some means of ensuring an incompatible externalizer doesn't read task nodes and these orphans make their way back into the output tasklist xml.
Safety should be improved with the new architecture. In 3.0 let's review how we could be more defensive and handle orphans better.
*** Bug 194367 has been marked as a duplicate of this bug. ***
Done. We have two mechanisms to 0guard against externalization failure and ensure recovery: 1) Copy, then write is performed when saving the primary data files. In event of a failure to read, the previous copy is restored and used. 2) A complete snapshot of primary data files is taken every half hour and placed in the .mylyn/backup folder. One backup is maintained per hour for the last 8 hours. One backup is retained for the last 12 days. Older backups are removed. Further improvements including validation of backups is being tracked on bug#233026.
Very cool. Btw, why don't we keep the task repositories and task list in the same file? They are quite tightly coupled. They could either be part of the same XML document, or both part of the same zip file.
-1 While the task list is coupled to repositories this is not a bi-directional coupling. There could be (headless) use cases for persisting repositories without using the task list.
(In reply to comment #4) > Very cool. Btw, why don't we keep the task repositories and task list in the > same file? They are quite tightly coupled. They could either be part of the > same XML document, or both part of the same zip file. We could place them in the same zip but this would complicate the current externalization story. Once we're dealing strictly with streams and the sink is determined by the ExternalizationManager rather than the participants, this could be feasible.
Agreed.
