Is it possible for an Subversion client to break a repository in any way? This could be any sort of destructive disruption, but it must be such that it cannot be recovered from without restoring the repository from a backup.
Obviously, deleting everything and then checking that it is easy to fix simply with a rollback, so I am looking for something more than that.
A Subversion client can either talk to a server to access the repository, or it can use a file:// URL to access the repository directly. In the first case, the server is responsible for the repository so the client cannot directly "break" it. In the second case, the client is responsible for the repository so bugs in the client can affect the repository.
In theory, it cannot corrupt the repository, as Subversion uses atomic commits (bugs in Subversion notwithstanding).
However, ignoring access control, clients can of course move/copy/delete the contents of the repository in new revisions. Old revisions continue to exist. You can, in theory, always recover to these old revisions, either with judicious use of svn commands or by the administrator removing later revisions.
In general, it's pretty safe, but do look at access control: http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.serverconfig.httpd.authz
Note: as Greg has intimated, it's slightly more complex when using a local repository as the client has direct filesystem access to the repository. Essentially, you have to trust Subversion.
If a client can break the repository in any way that requires a repository restore it's considered a very serious bug by the Subversion folks.
A quick look on their bug-tracker shows that they do occasionally have repository corruption bugs, but in the absence of a bug, it's not possible for a client to completely break the repository.