On 8/27/06, Max Bowsher <maxb1@ukf.net> wrote:
> Paul Cameron wrote:
> > Hello,
> >
> > I'm not sure if this should be posted to the users or dev alias, please
> > let me know if not appropriate for the dev list.
> >
> > I look forward to the new svnsync feature in 1.4. I see immediate
> > applications for repository backup via replication.
>
>
> > I feel another
> > interesting application would be for remote offices to perform all
> > 'non-commit' operations (log, update, etc.) against a local, replicated
> > server and commits against the remote, central server. The obvious
> > benefit would be much improved performance for non-commit operations
> > instigated from the remote offices. I believe this capability would
> > require clients that support two urls for the same repository. Is this
> > feasible and/or planned, or am I way off base here?
You could actually do it manually now, people check out from a mirror,
then have to do a 'svn switch --relocate' to the "real" repository in
order to commit. It kind of sucks that this is a manual process, but
it is feasable.
Note that to make this work you'll have to make sure that both
repositories have the same UUID, that's not impossible to do, but it
is a bit tricky. If you look at the svnsync tests they do it via a
svnadmin load and a dumpfile that contains only a UUID record.
> That's actually a pretty interesting idea, though I'd submit the
> alternate design of the client only having one URL, and having the
> server either 'passing through' write operations to the upstream server,
> or issuing some sort of 'referral' to the client informing it to re-try
> against a different server.
>
> My reasons for the alternate suggestion are:
>
> 1. Simplified user experience, they do not have to specify two URLs that
> must match.
>
> 2. Gives read-only server a hint that it should be looking for new
> changes to sync.
I'd love to see this ability baked in to either mod_dav_svn or
svnserve, it would simplify things greatly.
-garrett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Aug 27 21:58:35 2006