search

qbittorrent / qBittorrent

qBittorrent BitTorrent client
https://www.qbittorrent.org
Other
28.33k stars 3.98k forks source link

Settings and files migration #6661

Closed zeule closed 2 years ago

zeule commented 7 years ago

With profiles and portable mode in place, settings and files migrations have to be performed per-profile. We have two migration suggestions already: migrate settings files into configs location (Windows) and migrate data to ~/.local/share (UNIX). And this would be better to decide before 3.4.0 release, when profiles go into wild life.

My suggestion (looked up in Kile (KDE LaTeX editor) is: let's always write qBt version into the config file and then use this version as an indicator which uprgrate/migration steps are needed. In the app we can collect a dictionary of version->upgradeFunction opbjects. then comparing version from the settings file to the versions in this dictionary, we select required steps, sort them by version and run.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/44344131-settings-and-files-migration?utm_campaign=plugin&utm_content=tracker%2F298524&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F298524&utm_medium=issues&utm_source=github).
glassez commented 7 years ago

@evsh, do you want to support bidirectional migrations?

glassez commented 7 years ago

migrate settings files into configs location (Windows)

Apparently, the currently used config location is correct. As I said in another issue:

As I understand it, AppData/Roaming is for the data/settings that can be moved between different computers in a domain, and AppData/Local is for computer specific data/settings. So current behavior is correct (maybe, except some particular settings).

zeule commented 7 years ago

@evsh, do you want to support bidirectional migrations?

No, I don't. Does anybody want to write twice more migrating functions?

Apparently, the currently used config location is correct.

OK, I missed that somehow. Then only one possible migration is under consideration.

glassez commented 7 years ago

No, I don't. Does anybody want to write twice more migrating functions?

+1 I don't think it is implementable at all.

And this would be better to decide before 3.4.0 release, when profiles go into wild life.

+1

sledgehammer999 commented 7 years ago

This is the first time I saw this. I am bit confused what the problem is here that you're trying to solve. Are you talking about the upgrade/migrate code already in place or you talking about somehow migrating configs and data files elsewhere?

If the 2nd part why is it needed to do that?

zeule commented 7 years ago

We were discussing config migration from version to version and that migration functions are scattered all across the program, and that migration should be somehow controlled by Profile objects.