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