On Sep 10, 2007, at 07:36, Veyret Stephane wrote:
>>> My firm has many sites with network problems between them.
>>> Because of this, we try to implement a master/slaves repository
>>> structure with the following rules:
>>> 1. The master is the only repository to which we really commit,
>>> that means that every write operation done to any slave should
>>> actually be transmitted to the master.
>>> 2. Every read query arriving to a slave should be answered
>>> directly by the slave, after this one is sure to be up to date.
>>> 3. We need the system to be safe, even if we have a network
>>> breakdown. That means that if there is no connection between a
>>> slave and the master, all commit to this slave cannot achieve, of
>>> course, but all read operation should succeed anyway. And when
>>> the connection is comming back, the slave should synchronise
>>> itself with the master (at least at first read query).
>>> I've heard of the webdav proxy, but I am not sure this can help
>>> me for all this, and I didn't find how to use it. Can someone
>>> give me a clue?
>
>> It's meant exactly for what you want to achieve.
>> You can read about it more at
>> http://svn.collab.net/repos/svn/trunk/notes/webdav-proxy
>
> Thank you, Erik.
>
> I read the documentation you gave, but I still have a pair of
> questions :
> * If the master is modified while one of the slave is unreachable,
> they will be de-synchronized. I don't know hooks very well, but I
> think they cannot be set on read operations… Is there a way to re-
> synchronize the slave when connection is retrieved and slave
> recieves a read query (not sure I'm clear) ?
If you use Apache to serve your repository, then you can get fake
hooks on (well, after) read operations with my script here:
http://www.ryandesign.com/svnhookdispatcher/
But I haven't worked with slave repositories and svnsync, so I don't
know if that's necessary or helpful.
> * Do you have an idea (even aproximative) of when version 1.5 will
> be released ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Sep 10 23:24:30 2007