We have a main master repository and a number of mirror slave repositories at a bunch of locations that are set up as webdav transparent write-through proxies. These are synced by a process similar to svnsync, and this all seems to work okay.
However, it is inevitable that there is delay in the commits at the master repository propagating out to the slaves. This is not usually a problem, except when a large commit has been made where the transfer time of the revisions data is significant. In this situation the a client that uses the slave repository can have its commit blocked because it is unable to update to the latest revision because the slave repository is out of sync. This is unfortunate because it makes the slave repository somewhat useless until the sync has time to resolve itself. In a recent situation our slave was out of sync for around 3.5 hours. Is there a workaround for this situation? Switching the working copies back to the master is not really feasible at present because we run different UUIDs in the slave repositories, and I think our users would find this too cumbersome (or too complex!). I was thinking that if the client had knowledge of the master repository (perhaps as an additional property in the slave repositories properties) it would be possible for it to defer back to the master for the updates under these circumstances. I have a couple of other thoughts on this but I was wondering if anyone has some experience in this area? Regard, Simon
