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

mod_dav_svn not proxying LOCK and UNLOCK requests on a slave configured for write-through-proxy using SVNMasterURI

From: Mike Coyne <Mike.Coyne_at_PACCAR.com>
Date: Tue, 17 Feb 2009 13:05:35 -0600

Operating system: Redhat rhel5.3

Subversion upgraded to current 1.5.5

Compiled from srpms obtained from
http://the.earth.li/pub/subversion/summersoft.fay.ar.us/pub/subversion/l
atest/rhel5/src

 

We are currently reviewing a write-through-proxy mirror setup generally
using

 
http://svnbook.red-bean.com/en/1.5/svn.reposadmin.maint.html#svn.reposad
min.maint.replication .

 The hooks were set up On the slave , in particular pre-lock pre-unlock
set to only allow the repo owner lock or unlock as were
pre-revprop-change , start-commit per the documentation.

 

 The hooks were set up on the Master for post-commit post-lock
post-unlock post-revprop-change . the post-commit and
post-revprop-change were configured per the documentation using svnsync
sync svn+ssh://slave/... And svnsync copy-revprops svn+ssh://slave...
using our Kerberos environment via ssh to conned to the slave host.

 

The post-lock and post-unlock hooks on the server were setup to svn lock
-force svn+ssh://slave... -m "cryptic message about who locked it"
making use of the Kerberos environment again.

 

The slave - master pair worked as documented except for locking and
unlocking files. Svn lock calls to the "slave" were trying to run on
the slave and not being proxied to the master. The svn commit seemed to
work well , redirecting the user at the slave to the master applying the
commit and svn syncing the data back to the slave server. After some
looking at the mod_dav_svn module in the mirror.c file it appears that
in the dav_svn__proxy_merge_fixup() function the logic did not catch the
M_LOCK and M_UNLOCK method numbers prior to exiting the function .
leaving LOCKS and UNLOCKS un-proxied. I added / copied the code from the
M_MERGE as LOCK and UNLOCK which corrected the perceived problem of
not proxing the the LOCK commands from the slave to the master .

 

With the change below locks now get placed on the master from the slave,
the hooks on the master re-set a lock on the slave as the owner of the
repository so the users can see the locked files on the slave. It
commits etc seem to still work as documented.

 

Patch included ... is included . This may not be the best way to handle
the problem, as with the commit a search for /wrk/ set the slave to
proxy the preceeding PROPFIND or GET as well. I don't know if LOCK and
UNLOCK need the same ?

 

Thank you in advance for your time .

Mike Coyne mike.coyne_at_paccar.com

 

 

*** trunk/subversion/mod_dav_svn/mirror.c 2009-02-16
14:30:27.000000000 -0600

--- proposed/subversion/mod_dav_svn/mirror.c 2009-02-17
12:06:53.000000000 -0600

***************

*** 93,98 ****

--- 93,120 ----

              proxy_request_fixup(r, master_uri, seg);

              return OK;

          }

+

+ /* If this is a LOCK request or a request using a "special

+ URI", we have to doctor it a bit for proxying. */

+ seg = ap_strstr(r->unparsed_uri, root_dir);

+ if (seg && (r->method_number == M_LOCK ||

+ ap_strstr_c(seg, special_uri))) {

+ seg += strlen(root_dir);

+ proxy_request_fixup(r, master_uri, seg);

+ return OK;

+ }

+ /* If this is a UNLOCK request or a request using a "special

+ URI", we have to doctor it a bit for proxying. */

+ seg = ap_strstr(r->unparsed_uri, root_dir);

+ if (seg && (r->method_number == M_UNLOCK ||

+ ap_strstr_c(seg, special_uri))) {

+ seg += strlen(root_dir);

+ proxy_request_fixup(r, master_uri, seg);

+ return OK;

+ }

+

+

+

      }

      return OK;

  }

------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=1180433

Received on 2009-02-17 21:19:45 CET

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.