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
Received on 2009-07-30 22:59:22 CEST