Is there any way to down-format a Subversion repository to avoid messages like this:
svn: Expected format '3' of repository; found format '5'
This happens when you access repositories from more than one machine, and you aren't able to use a consistent version of Subversion across all of those machines.
Worse still, there are multiple repositories with various formats on different servers, and I'm not at liberty to upgrade some of these servers. ~~~
I suspect you have to export the repository and re-import it into the older version. There might be some format incompatibilities in the export format though - but since it's just a big text file, it would hopefully not be too difficult to strip those out.
According to the Subversion book, there's no way to do that. You will have to export the whole repository and then proceed to re-import it when you have the older version up and running.
In any case, I suggest you upgrade your SVN tools accordingly in the client machines, instead of playing dangerous games with your repository.
Decide upon a version and don't touch it until you're ready to upgrade to a newer version.
If you can't use the same version of Subversion across all machines, then you should set up a server process (either svnserve or Apache) and access the repository only through the server. The server can mediate between different versions of Subversion; it's only when you're using direct repository access that you run into this issue.
If the server will be an older version than the current repository format (which I don't recommend), then you'll need to export the repository using the newer version and import it using the older version.
The svnbook says this (about file:/// access vs setting up a server)
Do not be seduced by the simple idea of having all of your users access a repository directly via file:// URLs. Even if the repository is readily available to everyone via a network share, this is a bad idea. It removes any layers of protection between the users and the repository: users can accidentally (or intentionally) corrupt the repository database, it becomes hard to take the repository offline for inspection or upgrade, and it can lead to a mess of file permission problems (see the section called “Supporting Multiple Repository Access Methods”). Note that this is also one of the reasons we warn against accessing repositories via svn+ssh:// URLs—from a security standpoint, it's effectively the same as local users accessing via file://, and it can entail all the same problems if the administrator isn't careful.
Subversion guarantees that any 1.X client can talk to any 1.X server. By using a server you can upgrade server at a time, and clients independent of the server.