[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnsync - practical applications and plans

From: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2006-08-27 23:02:34 CEST

On 8/27/06, Ivan Zhakov <chemodax@gmail.com> wrote:
> On 8/27/06, Garrett Rooney <rooneg@electricjellyfish.net> wrote:
> > On 8/27/06, Max Bowsher <maxb1@ukf.net> wrote:
> > > Paul Cameron wrote:
> > > > 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.
> >
> ra_serf and mod_dav_svn with mod_cache should solve this problem much
> better than manual svnsync and some kind of redirection, if I
> understand correctly. Or I've missed something?

That's possible, although I don't know how much work has actually been
done on getting ra_serf and mod_cache working well together. It's
certainly another way to get this stuff working. Unfortunately, it
assumes that your clients are using DAV, and more problematic that
they're using ra_serf...

-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 23:03:07 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.