Hello, Le jeu. 22 août 2019 à 13:46, Andreas Stieger <andreas.stie...@gmx.de> a écrit : > > The only extra consideration that would need to be made is when using > write-through proxying (SVNMasterURI). Merely noting for completeness that > you would need an extra Location block in your httpd configuration. But your > back-up configuration does not include that. > http://svnbook.red-bean.com/nightly/en/svn.serverconfig.httpd.html#svn.serverconfig.httpd.extra.writethruproxy > > Andreas
Thanks for the detailed answer Andreas, you might have just pointed me to what I was seeking to reach for my requirements of "quite high availability" without a too complex setup. I doesn't need real and strong high availability. I don't mind not to be able to commit anymore if the master goes down, and while it's down. However, I clearly would benefit to have the slave still be up and up-to-date with the latest revision committed to the master in the event the master would go down. For one point, the repos would be available in read-only mode, but more over, if my understanding are good, depending on my configuration, this would mean I could ensure not to loose a single commit even if the master goes down. Is that last hypothesis valid ? In the documentation, I read "The extra bits on the end of each line aren't necessary, but they're a sneaky way to allow the sync commands to run in the background so that the Subversion client isn't left waiting forever for the commit to finish.". Regarding my desire not to loose any single commit, if I doesn't span the svnsync in the background (by not using "&"), this should hang the client process until the slave are synced, thus, when I commit, the commit would return only when the slave is synced. This would slow up commits, for sure, but if master and slave are connected to each other over a good network, this shouldn't add a lot of lag and could be a trade off I would be ready to take (for some repos) if this enable me to ensure that when a commits returns, it has been propagated to at least two (or more) physical servers. I would really appreciate your view on the feasibility of this setup. Best Regards, Pierre.
