[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-10-12 21:36:31 CEST

Justin Erenkrantz 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? 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?

Is there a header we could set on all of our REPORT requests that would
reveal the report "type" without parsing the report? I realize it wouldn't
be present for pre-1.5 clients, but perhaps that would be the flag to a 1.5
proxy server that it shouldn't listen to that client.

We promise compat between 1.x clients and 1.x servers, but I honestly
believe that we don't have to make such a promise about this particular
deployment scenario.

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

Gosh, I should hope so. For ra-neon clients, REPORT covers most of the read
operations. What would be the point of a proxy server that has to pretty
much hand off *all* its checkouts, updates, switches, diffs and commits to
the master?

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Fri Oct 12 21:36: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.