Bugzilla – Full Text Bug Listing
| Summary: | improve tasklist backup snapshot functionality | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Robert Elves <robert.elves> |
| Component: | Mylyn | Assignee: | Robert Elves <robert.elves> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P2 | CC: | leo.dos.santos, steffen.pingel |
| Version: | unspecified | ||
| Target Milestone: | 3.0 | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 196283, 202275, 226032, 226221, 229742, 230304 | ||
| Bug Blocks: | |||
|
Description
Robert Elves
Also investigate how the tasklist.xml is being written and ensure that it recovers gracefully in the event of malformed xml. Note that I have added a "Restore Task List from History..." action to the Task List's view menu. Upon failure to read tasklist, we should attempt to restore from a backup then inform user of the situation. TODO: * reduce disk usage of backups * investigate possible concurrency issues with restore due to periodic backup/save jobs taking place during restore. Deferring due to necessary fixes to concurrency and required api changes. Rob, we should consider to also save the workingset.xml file. When I had to restored my task list I always I had to reassign queries to my task working sets. (In reply to comment #6) > Rob, we should consider to also save the workingset.xml file. When I had to > restored my task list I always I had to reassign queries to my task working > sets. Excellent idea. Will do. That's a weird one. It should be out of our scope of what to back up, but due to the way that Task List restore happens the working sets are effectively blown away. If there's a straightforward way of our storing the working sets that makes sense to me too, but it seems like a separate bug. Snapshots are restored automatically in event of failure. Concurrency issues addressed using jobs api. Resolved. |