Re: Help Needed regarding svn master-slave configuration

On Wednesday 10 August 2011, Nico Kadel-Garcia wrote:
> On Wed, Aug 10, 2011 at 3:40 AM, Ulrich Eckhardt
> <ulrich.eckhardt_at_dominolaser.com> wrote:
[..]
> > 3. connect the repositories
> > This involves creating a post-commit hook that svnsyncs the changes to
> > the secondary repository and one for the rev-prop changes, but you seem
> > to have these set up already.
> > 4. create a transparent write-proxy
> > This requires Apache (the rest could be dove with svnserve, too) and
> > should also be documented. I never made this step though but only the
> > former three, since the write-proxy wasn't my requirement.
>
> Step 3 and 4 *are not enough*. The synchronization would have to occur
> at the "commit" stage, not the "post-commit", because "commit" has to
> be atomic with Subversion. Post-commit is nominally allowed to fail
> without stopping the commit operation. And the only support I've seen
> for that sort of thing is in Wandisco's "Multi-Site" tool.

I don't think I understand you. Or maybe you don't understand me....

Step three above means that new revisions in the primary repository are synced
to the secondary repository. I didn't explicitly say that this is a one-way
operation, but that's what I meant. In no case can you directly commit to the
secondary repository.

Step four is a setup of Apache that simply redirects any write request to the
primary repository while satisfying read requests from the secondary
repository mirror.

> If you use the post-commit approach, as soon as people send distinct
> commits at the same time to the different repositories, and each of
> them completes before performing a post-commit operation, of if one
> repository is disconnected for a while for whatever network or downed
> server reason and gets a commit that is not successfully transmitted
> ot the other repository, then the other repository receives a local
> commit before it can perform an svnsync syccessfully, the same
> revision number will have different contents in each repository and
> you are *screwed* trying to match them ever again.

I don't see this happening in any proper setup. The setup is not a net of peer
repositories but one primary repository and multiple secondaries. Changes will
only be made to the primary and then synced to the secondary.

What can happen (and, at least for a short latency, always does) is that the
secondary repository falls behind the primary, so someone updating from that
repository sees an older state than someone using the primary. This doesn't
cause severe problems though, at least not any more than those you get from a
broken connection to the primary which causes all commits to fail.

Uli

-- 
ML: http://subversion.apache.org/docs/community-guide/mailing-lists.html
FAQ: http://subversion.apache.org/faq.html
Docs: http://svnbook.red-bean.com/
**************************************************************************************
Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
**************************************************************************************
Visit our website at http://www.dominolaser.com
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************