Hacker News Reader

Comment by simonw | Hacker News Reader

My personal blog runs on Django + PostgreSQL, and I got fed up of not having a version history of changes I made to my content there.

I solved that by setting up a GitHub repo that mirrors the content from my database to flat files a few times a day and commits any changes.

It's worked out really well so far. It wasn't much trouble to setup and it's now been running for nearly three years, capturing 1400+ changes.

I'd absolutely consider using the same technique for a commercial project in the future:

Latest commits are here: https://github.com/simonw/simonwillisonblog-backup/commits/m...

Workflow is https://github.com/simonw/simonwillisonblog-backup/blob/main...

View on HN

A version history sounds great, but it's not really the problem I'm talking about.

I'm adding features and content to legacy Wordpress websites where the clients are liable to change config and add and alter content themselves via the admin portal. There seems no easy way to automate deployment from local development into production without accidentally erasing someone's changes, and to keep up to date with production without losing your own work.

It seems like a tricky problem to solve, and maybe a bespoke version control system might be required (e.g., throw CRDTs at the problem?), but essentially I should be able to diff and merge between my local work and the production version while clients are making their own edits.

Do those client edits get persisted to files on disk?

If so I'd be tempted to have a really shonky system - basically run a "git commit -a -m 'Updates' && git push" on an hourly cron, purely to capture their changes.

Merging in changes made elsewhere would still be hard, but at least you would know what was changed by them and when.

In Wordpress those changes get persisted to a MySql database, and now... SQLite? Seems like a lateral move. If they were files, it would be at least possible to diff against the production server, and to abort if there's differences since the last 'snapshot' (forcing the developer to pull them down at a later snapshot position)

That is awesome! Did you consider using the temporal_tables extension? I think it's basically like version history for tables. I haven't used this before personally though. https://pgt.dev/extensions/temporal_tables

I didn't - I hadn't seen that extension before, it looks like it could be really useful in the future!

For my purposes here the feature I care most about is backups - having my content backed up to a GitHub repo feels extremely robust, since I know GitHub mirror content to (I believe) three continents.

Reply on news.ycombinator.com