Editing a Subversion repository without a working copy: svnmucc

12 August 2026 · tested on Subversion 1.14, svn+ssh / svn:// release repository, pre-commit hook enforcing message format

The problem with a checkout

Release repositories tend to be large and deeply nested. Changing one deploy script means a checkout of a tree you do not care about, a build-up of stale working copies on a jump host, and a real risk of committing something you did not intend because the working copy had other local modifications.

For scripted or one-off edits, skip the working copy entirely.

svnmucc: multiple URL commands, one commit

svnmucc \
  put local/stack-deploy-or-update.sh \
      svn://svn.example.com/svn/release/trunk/projects/app/test/docker/stack-deploy-or-update.sh \
  rm  svn://svn.example.com/svn/release/trunk/projects/app/test/docker/portainer-compose.yml \
  -m "APP: unify deploy script, drop portainer compose" \
  --username builder --non-interactive --no-auth-cache

Everything on that command line lands as one atomic revision — which is the property you want when a change spans several files and half of it applied would leave the environment broken. The available operations are put, rm, mkdir, cp, mv and propset, all addressed by URL.

A few practical notes:

• put needs a local source file; write it to a temp file first if you generate the content.
• mv and cp take a revision-qualified source when you need one, and are server-side — no data leaves the server, so renaming a large binary is instant.
• --non-interactive --no-auth-cache belongs in anything running unattended; without it a prompt can hang a job forever, and with the cache you leave credentials in ~/.subversion/auth on shared hosts.

The commit message may not be free text

A pre-commit hook can enforce a per-project prefix in the commit message. Get it wrong and the commit is rejected — usually with a message that names the rule, but only after you have already assembled the change:

svnmucc: E165001: Commit blocked by pre-commit hook (exit code 1) with output:
Commit message must start with the project token.

So before scripting bulk edits, find the hook’s rule and encode it per target path in your tooling, rather than discovering it once per project. Also worth knowing: some hooks reject messages containing specific words. Check the hook, not just the format.

Verify from the repository, not from your shell history

svn log -l 1 -v svn://svn.example.com/svn/release/trunk/projects/app/test/docker/
svn cat svn://svn.example.com/svn/release/trunk/projects/app/test/docker/stack-deploy-or-update.sh \
  | diff - local/stack-deploy-or-update.sh && echo "content matches"

svn log -v confirms which paths the revision actually touched — the check that catches a typo in a long URL, where you happily committed a new file into the wrong environment’s directory instead of updating the intended one.

When not to use it

If you are making several rounds of edits and want to review diffs as you go, check out and work normally. svnmucc is for known, scripted changes: pushing a generated file, deleting a deprecated one, renaming across a set of environments. It removes the working copy as a source of surprises, and that is its whole value.

subversion svn deployment automation