Mention the File Entity Revisions module in the projects page as a companion module.

I'm moving this to the file entity module because this requires both changes to how the file entity is implemented and to the core files managed table.

This is something we'll have to do eventually but likely it will be a separate sub-module called file_revisions since we don't want this enabled for people by default. Marking as postponed but major.

I've been thinking about how file revisioning might work from the user's perspective. In Drupal 6, I had been using a full content type - "file", "image" etc, forcing users to create a new instance of that content type and upload the file there, then separately referencing that content item from other nodes. I was not providing any kind of upload field within the referencing node edit form.

So I'm curious - in the context of a referencing entity edit form, what is meant by the "original file" and how that is "updated", from a user's perspective. Is the "original" the referencing entity where the file was originally uploaded, via the filefield widget, mediafield widget etc?

In the referencing entity edit form, if there is an upload widget, how do you distinguish between the user

A: replacing that file with some other unrelated file, or
B: uploading a new version of the file

If A, you want a new file entity, if B, you want a new file entity revision, right? And you possibly do want to update other references to the file entity for B, but definitely not for A.

My experience is that users will just upload/replace files in an unstructured way wherever they have an "upload" button available, and they won't think about whether the upload is a new version of the same file. It seems to me that to support file revisioning from the UI, it becomes desirable to separate the act of uploading a file from the act of referencing the file, which is the workflow I force on users in Drupal 6.

Perhaps this is best discussed from the perspective of the module which provides the upload/reference UI, if/when there is a module that supports file revisioning. Or perhaps file entity should be responsible for providing the default revisioned upload UI?

Possibly relevant is this Media module issue: #1398896: Decouple Add media page from media browser

I'd love to get file revisions working w/ media too. I'll keep an eye out for something to test.

I've been working on a patch for epsacrop that enables "revision support" for file entities. #1497484: Unique Crops Per Node/ Revision The implementation is pretty ghetto right now. Essentially, I just clone and reattach file entities to the revision in hook_node_presave. This functionality probably belongs in a module of its own, but I'm strapped for time atm.

So here's my thoughts on revisions. It's a good idea and something I knew eventually would be done. But until core has a better generic revision API, and until we're getting a large percent of the user base clamoring for it, it's probably not going to be appropriate to put into file_entity and I would encourage it to live in a separate project. Figuring out how it actually works for storing the actual files in the file system as well is a big thing too.

That said, if we need to fix up file_entity to support revisions in a way that will not block merging the module into d8, I'm for reviewing and getting those fixes in. But we continually have to be aware that this module is one we want to merge as-is into core. We can't add dependencies on Entity API or UUID if that functionality isn't going to be available or implemented in D8 core.

Overall I think we will find working on #1123570: Replace file while retaining field metadata much more useful to a wider audience of end-users until revisions becomes a better option for us to implement here.

I think we have to be careful about derivatives here. Perhaps that's beyond the scope of this discussion. I'm not sure that that would be a blocker but I think there would need to be agreement between how we handle revisions and derivatives.

As per the reuse- in cases where a file is being reused but should retain the original data then it should be implemented as a new file, not a reuse. I'm completely unclear on what the UI for that is but I think the obvious use case is wysiwyg inserting- as tsvenson notes.

Perhaps when one goes to edit the file you have the option to replace all or the single instance- in the single instance it actually creates a new file?

How hard would it be to do revision only on text field attached to the file entity? The opposite to #1123570: Replace file while retaining field metadata that Dave mention. I know the ideal would be a revision of the entire file entity.

+1 for this.

A contrib module I found, sounds promising: https://drupal.org/project/file_entity_revisions

Edit: As of 20 September 2013, it is brand new. Needs a lot of work still, beware unless you are willing to get your hands dirty.

I just released https://drupal.org/project/file_entity_revisions.

FYI: Before I started working on that module I spoke to Dave Reid on irc and spoke to him about this issue. I decided to go with a different module as per the recommendation on this thread and because we wanted to add a couple of extra features.

The module is very early but we already pushed it to multiple sites, seems to be working great.

In short this thread is now fixed.

I'm going to marked this as "Fixed" even thought it's technically not in the file_entity module. Maintainers: Change it to what ever you feel is appropriate.

As far as I'm aware there are no major issue with File Entity Revisions and it technically does very little :-)

For a full list of features please do check the project page.

Thanks.

...this is just great! Let's give the new project a popularity boost in order to get more people testing it.

...

Added to https://drupal.org/project/file_entity

Thank you Dave.