I've been reading up on svnsync to create a read-only copy of our repository, but I don't really understand what the point of having a read-only copy of the repository is. If the master goes down for some reason can the read-only copy become read/write so people can commit to it? If not, then what's the point of a read-only copy?
I don't know if you can make you sync read/write, but there is many cases when you want to check out the content of a repository without ever allowing comiting to it. Below are two cases very similar to what we do at the place I work:
Imagine this is a public open source project, you can allow check-out for anybody but only expect contributions through patches or bug reports (also the copy is put on a public server and the main one is kept in a protected private network).
You may want to use the content of the svn through an svn export in an automated build system (or some analysis tool), but choose to sync not all the time but only when main svn is in a stable state (imagine some intermediate commits could leave the code in an unstable state where the code is not compiling).
Assuming you're talking about your own private repository, two reasons for a read/only copy of anything - a database or a source code repository or xyz - are to relieve load and improve performance.
If you're running any kind of analytics over your repository, say a process that touches every revision, then this might place a high load on your main repository, degrading performance for developers. Syncing a read/only copy is a way to relieve that load, allowing you to get the job done without causing degredation for key users.
A similar argument can be made over latency - easier to pull down from a local read/only copy (essentially a cache) than to pull from another office over a VPN or similar link.
Read-only repositories maintained by svnsync are typically set up to provide near real time backup of a master repository. The copy is considered read-only because making changes to it by means other than svnsync will prevent svnsync from working properly.
In the situation that your main repository is lost, your backup repository can become the new master. For all practical purposes the copy is identical to the original master as of the last run of svnsync. You could rebuild the original repository by copying the files from the backup repository and continuing as before.
Alternatively, clients with working directories based on the original master can perform an svn switch --relocate
operation to update the server URL to point to the copy and continue working without a hitch. Of course once clients start using the backup to make commits then it can no longer be the target of svnsync commands and effectively becomes a new master repository and you'll want to create a new backup.
Make a backup of your favourite open-source program sources :).