Hi Elaine,
Thanks for taking the time to contribute to the Subversion users community!
> The key problem with using svnsync for multiple Subversion repositories
> distributed over a WAN is its reliance on a master-slave architecture.
Right. Or, at least, partially right. If you want a master-slave
architecture, there's no problem ofcourse :-)
> While
> svnsync does provide the advantage of having local read-only repositories at
> each of the remote development sites, only the master repository is
> writeable.
True.
> The master repository is then replicated to the read only slaves.
> However, replication can place a significant load on the network and
> servers. In addition, best practice requires the master server to be
> unavailable for write operations while replication is taking place, in order
> to avoid file corruption and other inconsistencies.
This is however incorrect: svnsync accesses the repository the same
way as any other accessor would: for example through http:// or svn://
access layers. These layers guarantee repository integrity. There's
also no need to take the repository off line while synchronizing
(neither the source nor the target).
Synchronizing happens through the same mechanisms as checkouts do, so,
as far as network load is concerned, synching with svnsync takes the
bandwidth required to do an update of a working copy at the revision
before the one being synched to (for each revision being synched).
> For these reasons,
> replication tends to happen on an infrequent basis, leaving the read-only
> slave repositories that remote sites do their checkouts from out of sync
> with the master much of the time.
If you use the 1.5 WebDAV proxy feature, you have to sync every
revision immediately exactly because of this problem. As explained
above, there's no reason to wait, because svnsync is just a 'normal
client' as far as the server is concerned.
> As a result, commit failures due to update
> conflicts on the master repository can become a problem. In order to avoid
> commit failures, developers at the slave repository sites have to do updates
> over the WAN against the master Subversion repository before doing their
> commits.
This is a possibility but shouldn't be necessary unless commits are
extremely large or the network between the master and the slaves is
very slow (taking a lot of time to be synced).
> This can negate most of the expected network performance and
> developer productivity benefits of using svnsync in a distributed
> development environment.
>
> Other solutions such as svk do allow multiple repositories to be readable as
> well as writeable, but there are no guarantees of consistency across the
> repositories. A commit can succeed on a developer's local repository where
> there are no conflicts, and fail when it's copied to other sites'
> repositories due to update conflicts. This can make administration extremely
> difficult.
>
> WANdisco solves these problems by turning distributed Subversion
> repositories into peers. All of the repositories are writeable, and
> consistency across the repositories is guaranteed. WANdisco's active-active
> replication capabilities allow developers to work at LAN speed over the WAN
> for both read and write operations, while keeping all of the repositories in
> sync, in effect in real-time. WANdisco also provides self-healing
> capabilities that automate disaster recovery after a network outage or
> server failure.
This, ofcourse, is a good solution too: WANdisco has been providing
their solution for some time now (how long?) and as a consequence have
experience providing exactly the required functionality...
I hope you don't mind the clarifications.
bye,
Erik.
> Res Pons wrote:
> >
> > Thank you for the link :)
> >
> > ----Original Message Follows----
> > From: "Andy Levy" <andy.levy@gmail.com>
> > To: "Res Pons" <pons32@hotmail.com>
> > CC: users@subversion.tigris.org
> > Subject: Re: Subversion Mirroring
> > Date: Wed, 12 Apr 2006 13:33:53 -0400
> > MIME-Version: 1.0
> > Received: from pproxy.gmail.com ([64.233.166.180]) by
> > bay0-mc4-f9.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Wed,
> > 12
> > Apr 2006 10:33:54 -0700
> > Received: by pproxy.gmail.com with SMTP id c63so1588023pyc for
> > <pons32@hotmail.com>; Wed, 12 Apr 2006 10:33:53 -0700 (PDT)
> > Received: by 10.35.15.11 with SMTP id s11mr488683pyi; Wed, 12 Apr
> > 2006 10:33:53 -0700 (PDT)
> > Received: by 10.35.70.10 with HTTP; Wed, 12 Apr 2006 10:33:53 -0700 (PDT)
> > X-Message-Info: JGTYoYF78jEHjJx36Oi8+Z3TmmkSEdPtfpLB7P/ybN8=
> > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta;
> > d=gmail.com;
> >
> > h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
> >
> > b=HMXPherLwn30sEv1ny1B9al3gwyTrlCG8fMAsXIGZJ31t1Sip4Kr7xZZnXixtQGv4HZAyXelDWC4vbi5jXv0UBaP12twqDOy0a52+PZQ2LesciKQ5p/R/6XTjeQkcYqQMtjrjYWdxYpn1m1uClDqCoa2i9PsAgasns70JkNjWjc=
> > References: <BAY113-F256ADBA80BA8461AE91DECCC20@phx.gbl>
> > Return-Path: andy.levy@gmail.com
> > X-OriginalArrivalTime: 12 Apr 2006 17:33:55.0408 (UTC)
> > FILETIME=[45DF8500:01C65E57]
> >
> > On 4/12/06, Res Pons <pons32@hotmail.com> wrote:
> > > Hi Forum
> > >
> > > Could someone please tell me how I go about mirroring SVN? Our
> > > international offices are very slow to login to our US repo server.
> > I'm
> > not
> > > sure how to go about this? Any ideas?
> >
> > http://svk.elixus.org/
> >
> > _________________________________________________________________
> > Is your PC infected? Get a FREE online computer virus scan from McAfee(r)
> > Security. http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Subversion-Mirroring-tf1439416.html#a13052969
> Sent from the Subversion Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Oct 5 17:39:31 2007