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

[PATCH] Allow transparent slaves to handle REPORT?

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2007-10-12 19:44:00 CEST

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?

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

WDYT? -- justin

mod_dav mirroring: Allow REPORT requests to be served locally by the slave.

Index: subversion/mod_dav_svn/mirror.c
===================================================================
--- subversion/mod_dav_svn/mirror.c (revision 27151)
+++ subversion/mod_dav_svn/mirror.c (working copy)
@@ -36,6 +36,7 @@
         /* We know we can always safely handle these. */
         if (r->method_number == M_PROPFIND ||
             r->method_number == M_GET ||
+ r->method_number == M_REPORT ||
             r->method_number == M_OPTIONS) {
             return OK;
         }

---------------------------------------------------------------------
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:44:09 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.