There are a number of ways you can do this. The following method is just one possible solution:
Define two tables, Documents, RevisionHistory.
Documents will have one record for every document your database controls. RevisionHistory will have one record for every version released for every document--including the container field that stores the document or a reference to it.
That gives you this relationship:
Documents::__pk_DocumentID = RevisionHistory::_fk_DocumentID
If you define a serial number field, __pk_RevisionID, in RevisionHistory you can devise one layout where a one row portal to RevisionHistory can be set up. This portal can be sorted by __pk_RevisionID in descending order so that only the most recent RevisionHistory record is shown in the portal. A separate layout that only Full Access users can access can be used with the same portal setup, but with multiple rows and a scroll bar enabled so that all revision history records may be accessed for a given Document. It would also be possible to set up a list layout based on Revision History for listing all revisions for one, a group or all documents--with revisionHistory records grouped under sub summary parts "when sorted by _fk_DocumentID".
I am a little confused about how the new revisions would be entered. If someone wants to create a record for a revised document of one of the documents present on the Documents layout, do they simply create a new record on the Documents layout? Or do they need to go to a layout specifically for RevisedHistory? Also, you mentioned there are multiple ways of doing this, did you list two ideas here? It seems like you did but I am also a little unclear about the second one you mentioned- when you say 'set up a list layout based on Revision History', do you mean create a list view of the Documents layout and sort by the RevisionID field? If you could please elaborate on both ideas that would help a lot. I think I am confusing different steps and not understanding what you said. Thanks!
If someone wants to create a record for a revised document of one of the documents present on the Documents layout, do they simply create a new record on the Documents layout?
Layouts and tables may have identical names but they are different objects in FileMaker. You would log a new revision by creating a new revisionHistory record in the RevisionHistory table, inserting the new document file into the container field of this record. The Document Record would remain unchanged but the one row portal would show a new revision of that record. All data specific to that revision, approvals, revision date, revision number, etc would be fields defined n Revision History. The title of the document and other data specific to all versions of the document would be defined in the documents table. (A different layout based on documents can be created that lists all revisions in a muliple row portal with a scroll bar that can allow you to access past revisions of the document.
What I have described so far is how to hide the old revisions. To log a new revision will take some scripting and an additional layout. There are many ways you can do this. You can click a button that pops up a new window where you'd insert the revised document file and log other revision infor or your button can just change layouts to one based on RevisionHistory where you can record this info.
Here's a script that changes layouts and creates a new RevisionHistory Record and links it to the current Document Record:
Set Variable [$DocumentID ; value: Documents::__pk_DocumentID ]
Go to Layout ["AddRevision" (RevisionHistory)]
Set Field [RevisionHistory::_fk_DocumentID ; $DocumentID]
#This next line automatically se's up the insert of the new document file. Leave it out if you don't want this to be automated
Insert File [RevisionHistory::DocumentContainerField]
Click a button that performs this script and the system will change to the AddRevision layout and pop up a dialog for selecting the document file to be inserted. After inserting the document, the user would fill in any additional revisionHistory fields and then click a button to return. A script that does this in a floating window would be very similar but with added steps to open the window and simulate the "modal" behavior typical of a dialog box. (Dialog boxes don't let you interact with other windows in the application until you close the dialog box.)