I'm splitting an SVN repository into two: project1, and common. This way, I can also make project2 which also depends on common.
project1 will contain an svn:external link to common. I'd like people to constantly develop against the HEAD of common, but literally pegging an svn:external to HEAD causes problems (e.g. tags will reference the current HEAD instead of the HEAD at the time of tagging). Manually pegging a static revision is annoying because if we don't update project1 for a while, then it's manager's will be more reluctant to take all of the changes from common as untested changes become a risk. That leads to forking which we want to avoid.
How can one work around this?
Run this script as a cron-job or systemd.timer from a linux server (using an account with write access to the repository).
This solves the problem where reverting to an older revision of project1 will also revert to the version of common used at that time by constantly updating the pegged svn revision.
As an added bonus, if someone updates common, all projects running this script will automatically commit an external property update which can trigger CI (using something like Jenkins). That means a commit to common will immediately be tested on all dependent projects.
The limitation is that it only supports externals configured relative to the same server's root.