[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: Roland Schwingel <roland.schwingel_at_onevision.de>
Date: 2006-08-28 10:00:20 CEST

Hi...

Max Bowsher <maxb1@ukf.net> wrote on 27.08.2006 15:11:34:

> 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?
>
> 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 am following this thread with great interest. I have the same need as
others
here. A master svn repos on the one side of the atlantic and a slave one
on the other side. And having this read-from-local write-to-remote
automatism
would be real great! If I would be able to vote for a svn feature I
would add
+1000 on this ;-)

Roland

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Mon Aug 28 10:00:36 2006

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

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