Versions 2.0

@icewind1991 as discussed

Right now versions are handled suboptimal.

• When a file is moved to the trash all the versions are moved as well
• When a file is moved back all the versions are moved again

This basically puts a huge load on the server. Because it has to move data around. Better would be to just store the versions on a logical place (by default appdata as versions don't count towards quota anyway). That way the files can just stay where they are and we only start deleting them when they are all removed from the system.

Removal could be done similar to https://github.com/nextcloud/server/pull/9420 so in a backgroundjob.

• Shared files don't mean shared versions

Right now versions are bound to a user not to a file. Being bound to a file makes more sense as it will allow shared versions.

We would need to filter out versions from before the share time. So that other usres can't see my pre-cleanup versions.

• No storage versioning support

S3 for example has native versioning. It would be awesome to use that to save a lot of transfers back and forth.

Idea:

Storages can declar a versionhandler (or whatever you call it). By default this is our base handler that will store versions in appdata. But S3 home storage could do other things.

The current files_versions app would contain basically 2 small apps:

1. The default version handler. To implement the default versioning.
2. The DAV API to list/see/delete/restore versions

• This interfaces with the storage versionhandler

Of course it will also need to handle the current versions in a hybrid way. As migrating this all over will have to happen live to avoid significant downtime.

Limitations:

I would propose to have the version handling for now bound to the main storage. So if you have S3 you can eventually move to S3 versions if you have 'normal' storage you can have that.

Else we'll have to start moving versions around cross storage. Which I want to avoid.

Open questions:

What to do if a recipient moves a file out of a shared folder?

Start by reviewing the current files_versions app, its DAV API, and the approach described in pull request 9420. The issue proposes a broad redesign involving storage handlers, shared-file visibility, migration, and background deletion, but does not identify specific files or tests. Done would require an agreed architecture and implementation plan before coding can begin.