SPIKE: Exposing published file revisions

[mandolyte]

Today files are changed ("revised") and are published in a release. But since releases are a snapshot of the master branch, a release version has not relationship to a revision of a file in the release.

However, the revision chain of a file can be derived by examining the SHA value for each file across all releases. For background:

• on Zulip: link
• on personal notes: link

There is a collaboration thread on Zulip where problems and solutions are discussed:
link

[richmahn]

A release doesn’t necessarily have to be from the master branch but usually is. Could be from a totally new branch. This shouldn’t matter as to should just be concerned about diffs between releases rather than commits.

[mandolyte]

Note: the Zulip thread has a lot of information and discussion of edge cases. This post will be updated to have a link to a document where the Spike findings are written up.

folder is https://drive.google.com/drive/u/1/folders/1t_aqc5801cK7g_XY72d6pV26pSIMFZ2t

[mandolyte]

Here are the issues arising from this spike:

• New database table to track published (prod) file revisions dcs#325
• Catalog Next File Revisions API dcs#326
• Content Validation On Release dcs#327

These address the creation/maintenance of a file revisions table, the API to make the content of said table to applications, and the possible integration of Content Validation into the Release Process.

@richmahn @birchamp @BincyJ