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

Re: WebDAV proxies and locking

From: David Glasser <glasser_at_davidglasser.net>
Date: Fri, 31 Jul 2009 07:23:30 -0700

Use of WebDAV proxy considered harmful anyway until Issue 3445 is
fixed. (Which may not even be possible.)

--dave

On Thu, Jul 30, 2009 at 1:59 PM, C. Michael Pilato<cmpilato_at_collab.net> wrote:
> I'm trying to think through and solve our general problem with WebDAV proxy
> usage and Subversion locks.
>
> Let's begin with the naive setup of a single slave server, proxying to a
> master, with svnsync mirroring (from master -> slave) in between (and with
> some authn protecting writes).  We checkout a working copy on a client
> machine from the slave, and try to lock a file.  Locking succeeds, but
> there's no replication of the lock from the master to the slave, so the
> master repository has the file locked, the slave repository does not.  Upon
> running 'svn update', we are told that the lock was broken.  We can't commit
> to the file, though, because from the master's point of view, it remains
> locked (and we ain't the locker!).
>
> Clearly, we need to replicate the locks from the master to the slave.  So we
> install a post-lock script on the master that uses 'svn lock' to lock the
> same path on the slave.  Now, you need a non-trivial authn/authz setup to
> even make this even feasible.  If you use a standard "svnsync" user for lock
> replication, you wind up with the file locked on the slave as desired, but
> by the wrong user.  But even correcting this by locking the slave's file
> with the same user that holds the lock in the master falls short, because
> the lock token in the slave will not match the one in the master.  'svn
> update' after locking a file in this setup doesn't claim the lock was the
> broken, but it claims that the token lives in some other working copy.
>
> What would help here is a way for the client tools to (optionally) specify
> the desired lock token.  (Or, if not the client tools, at least some new
> 'svnsync copy-lock(s)' subcommand.)  Is that a sane thing to allow?  If not,
> is there some other remote lock replication approach that we can suggest to
> folks who need this?
>
> --
> C. Michael Pilato <cmpilato_at_collab.net>
> CollabNet   <>   www.collab.net   <>   Distributed Development On Demand
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377143

-- 
glasser_at_davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377406
Received on 2009-07-31 16:24:32 CEST

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.