On Feb 10, 2012, at 16:34, Stefan Sperling wrote: > On Fri, Feb 10, 2012 at 04:20:02PM -0600, Ryan Schmidt wrote: >>> While replicating commits, svnsync performs the exact same kinds of >>> write operations against the slave servers that happen on the master >>> repository when a client makes a commit. >> >> So when using svnsync one should always use a separate and preferably >> local copy of the repository(ies) on each server, yes? > > Yes. That's the entire idea. Revisions are replicated by performing > a commit against the slave. The only difference to a normal commit > is that data originates from an existing revision of a different > repository, rather than a working copy.
Here you're talking about a commit that happened on the master, and is being replicated to the slaves. I understand how that works. I was talking about a commit that is done against the slave, and is proxied to the master. The book says: http://svnbook.red-bean.com/en/1.7/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy "All read requests go to their local slave. Write requests get automatically routed to the single master server. When the commit completes, the master then automatically “pushes” the new revision to each slave server using the svnsync replication tool." So thinking all this through, I agree svnsync does not make sense if you are hosting a repository on a SAN and trying to connect multiple svn servers to it. But it sounds like it would work fine, if you simply don't use svnsync. Configure one server to be the master (let it accept write requests). Configure the other servers to be slaves (read-only, and proxy any incoming write requests to the master). All servers point to the same repository data on the SAN and it can't get corrupted because only one server is writing to it. Sound ok?
