researchr.co should support version control. This means not just being able to revert a single field or component to a previous value, but being able to revert the whole site to a prior state — very useful after a hacker attack. Standard version control features like tags and branches would be a beneficial side-effect. Without version control, I’m afraid to try clicking any of the many mysterious buttons or changing fields because I don’t know what the effecters will be on the site, and I’m concerned that I won’t be able to figure out how to change things back.

The obvious implementation would be to use something like git’s versioned file system to actually store the informaiton from researchr.conf

On the SIGPLAN EC, we are abandoning the content management system that we adopted only a couple of years ago precisely because it does not support version control. I believe that versioning is an essential requirement for supporting the academic life-cycle.

Submitted by Andrew P. Black on 1 April 2014 at 18:32

Of course, researchr.conf is based on a data base. And of course we make regular back-ups of our databases. (Can you check that backups have been activated, Elmer?) Backups provide safety against attacks.

Fine grained version control is a feature to guard against the sort of user mistakes that you are referring too. That’s a different type of issue.

Saving the site in a git repository would be akin to storing a data base dump in git. That might be a good mechanism to efficiently store version histories, but is not fundamentally different.

The state of a site such as this, does not easily translate to a set of documents that would be stored in git. It is possible of course. But efficient operation of the site requires a database.

The only really dangerous operations in the app are delete operations. These are always clearly marked in red and ask for confirmation (Elmer?).

The key version control feature we need is the version history of texts.