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

Re: [PATCH] Allow transparent slaves to handle REPORT?

From: Mark Phippard <markphip_at_gmail.com>
Date: 2007-10-12 19:50:21 CEST

On 10/12/07, Justin Erenkrantz <justin@erenkrantz.com> wrote:
> Right now, our mirroring code lets the REPORT methods get sent to the
> master rather then dealing with it locally. Back in 2002 when I wrote
> this code, we weren't using REPORT as much as we are today. =)
>
> Most of the REPORT methods are read-only and can be served by the
> slave using its copy of the repository. The one exception I can think
> of is getlocks. So, if we apply this patch, the getlocks report won't
> be proxied correctly - IOW, the slave will think there are no locks
> while the master actually does have a lock. Is this a big deal? Are
> sites that have geographically distributed mirrors going to be using
> locking anyway?

I think it is reasonable to assume the answer is Yes, they will be
using locking. How would this manifest to a user? svn lock would
presumably still need to lock at the master so wouldn't it still
correctly fail if someone else held a lock? What commands use
getlocks?

> The only other questionable report would be
> getmergeinfo - and this depends upon what svnsync/replay transfers
> across. Would the mergetracking info be the same on the slaves?

I can't help here.

> AFAICT, all of the other REPORTs that we use should be able to be
> serviced by the slaves without any worry.
>
> WDYT? -- justin

If the request is a REPORT is it possible to peek inside the request
to learn more before deciding to proxy it?

-- 
Thanks
Mark Phippard
http://markphip.blogspot.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Oct 12 19:50:33 2007

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.