On Sun, Aug 14, 2011 at 9:34 PM, Simon <tzueskj...@snkmail.com> wrote: > 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!).
This is *precisely* the situation I warned about.... last week? When someone else was trying to set up that kind of live mirror pretending to be a master-master setup. I'm quite 3.5 hours is impressive, though. How did that happen, if you don't mind giving more detail. > 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 This looks like what WanDisco's "Mutli-Site" tool does, with some interesting proxying and production grade state management to designate a preferred master and proxy traffic to it as necessary, especially commits. There's an explanation of it at http://www.wandisco.com/subversion/multisite. Note that this is also one of the cases where the selection of the Apache license for Subversion, rather than GPL, means that Wandisco can build a business plan on selling these commercially enhanced versions of Subversion without ever publishing the code.....
