[Request] Optimize storage of bottle versions

[gbtb]

Is your feature request related to a problem? Please describe. Current implementation of versioning mechanism is sub-optimal in terms of storage space. Each version folder is basically a full copy of prefix drive_c folder at some point in time.

Describe the solution you'd like I'd like to discuss possible solutions we can implement.

Describe alternatives you've considered

1. Storing version folders inside an archive Pros: Simple to implement. Cons: not as effective for multiple versions, since files still have multiple compressed copies.
2. Use hard-links for a files in new version, which has not changed since previous version. Pros: also seems simple. Cons: requires manual file operations and we will still have at least two copies of files - one in a version folder, and one in a bottle folder. So if you install a game with prefix size X and then make a version out of it, you will have 2X space taken, and only for subsequent versions hard links will get you profit.
3. Use an OverlayFS under the hood. Tutorial in Arch wiki is very simple - all you need is basically one mount command and it works. Pros: It is baked into Linux kernel, similar methods is used by Docker and it is proven to work well for Docker images, it will save the most space on disk. Cons: mount command requires sudo, it is more complex in terms implementation, and also it is also possibly will add a performance penalty to wine

Additional context

[mirkobrombin]

I considered using symlinks but this led me to create another feature (still under development), namely Layers, where each dependency and program is on its own layer and these are mounted on demand.

I am aware that versioning can be optimized, perhaps using something like OSTree or trivial symlinks but at the moment I can't get into this. I'd like some other developers to join this conversation.

[TiBeN]

Why not use git as a backend for this feature ? One state = 1 commit or 1 tag. Just have to make "git checkout <tag|commit>" to go back to a previous state. Pretty quick.

You could imagine others features around git like restoring bottles in other installations, automatic backup and restoring points in time etc..

Also, using branches could help to reduce disk space by creating new bottles simply backed as a git branch. No core wineprefix files duplication anymore...

Maybe installing a program could trigger the creation of a new branch. Uninstalling the program simply resulting as destroying the branch. And launching the program would just trigger to switch to the branch of the program.

In fact i suppose the entire wineprefix could be driven by git (minus symbolic link but i don't think its a blocker).

This would just require two repos, one per arch (32/64). And the rest would evolve like git branchs and tags.

Sorry for the edits but this idea made me brainstorm. I think this idea could definitely solve the wineprefix duplication issues in Wine. Please let me now if you are interested by this idea. If not i may try to create simple cli POC during my holidays. Or at least manually driving a wineprefix with git to see if it makes sense.

It could be the implementation solution around your concept of "layers" too: https://github.com/bottlesdevs/Bottles/issues/510

[TheEvilSkeleton]

Why not use git as a backend for this feature ? One state = 1 commit or 1 tag. Just have to make "git checkout <tag|commit>" to go back to a previous state. Pretty quick.

He's considering using OSTree instead, which is essentially git for binary files and more suitable for this purpose, from what I understand.

[mirkobrombin]

closed by 5cfe7a81351559b0b257b39a3ff6812d7dd87210