Repos' Subversion images
First of all, why do we use svn? We see it as a self-hosted blob store with an audit trail. It comes with an HTTP API and has permanent URLs to every revision at every path. It stores binary files efficiently and supports versioned metadata and individual file branching.
For write access REST we use rweb.
Subversion project activity is slowing.
We see 1.8.x as latest stable, partly because SvnKit is inn't completely compatible with 1.9.x.
There is a branch
1.9.x for those who are interested in the backend optimizations.
At Repos our source is in git, but we haven't found something better than svn for documents, graphics and configuration.
Our next best bet would be something like IPFS, but we're in no hurry.
Runtime configuration, as environment variables:
ADMIN_REST_ACCESSnon-empty to enable
Runtime configuration, as CMD override:
-DAUTHN=anonenables mod_auth_anon so that usernames from reverse proxy end up in svn logs
-DAUTHZ=svnenables mod_autnz_svn with path
-DRWEB=fpmis used from
solsson/rweb-httpd(see below) to enable rweb config directives
/r Location alongside
For content hosting you may want to keep URLs backend-neutral.
For that purpose this image will expose
/r as read-only variant of
This is done only if
-DAUTHN=anon, where it's up to the reverse proxy to expose
/r or not.
Also we only enable this with
Because svn runs in httpd, and (mod_)php doesn't scale in httpd,
we recommend using httpd and php:fpm together, with rweb at the same path.
This image and the one below is meant to be used together. In Kubernetes that makes a good Pod.
svn-httpd with rweb installed and enabled.
Tries to keep two repositories with same uuid in sync.
Deprecated. Omit the tag and get the full rweb instead.
Stable Debian with latest subversion release. Useful because apt repositories are far behind.
docker run -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd)/:/source solsson/build-contract