@mcc This gave me an idea you could play with for Tusky,...

This gave me an idea you could play with for Tusky, for your case where you frequently roll backwards/forwards:

Instead of versioning a pref file as a whole, suppose you versioned it by sections? E.g, start with a recent past version, vN:

* Section # 0 is baseline preferences, that all versions support and you can always preserve.
* Section # N includes all prefs vN supports, so any fairly stable pref is preserved.
* All newer prefs go into a section by SW version which added them.

Like 14 July at 8:49 | Wall-to-wall | Open on wandering.shop

2 comments

Clifton Royston

@mcc

The code to implement it practically writes itself.

14 July at 8:56 | Open on wandering.shop

mcc

@CliftonR Thank you for the thought but we're using a particular system. We didn't create our own prefs/persistence format, we're using an Android feature called "Rooms". It's basically managing an sql database for us, changing "file formats" means running some sql ALTER TABLEs, and upgrade means running the registered ALTERs in a particular order (and Android decides which upgrade SQLs to run). So to improve things we'll have to work within this system.

14 July at 14:46 | Open on mastodon.social