On Sun, Aug 14, 2011 at 9:34 PM, Simon <tzueskj268_at_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.....
Received on 2011-08-15 15:31:28 CEST