You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2009/07/30 20:59:04 UTC
WebDAV proxies and locking
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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377143
Re: WebDAV proxies and locking
Posted by David Glasser <gl...@davidglasser.net>.
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<cm...@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 <cm...@collab.net>
> CollabNet <> www.collab.net <> Distributed Development On Demand
>
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377143
--
glasser@davidglasser.net | langtonlabs.org | flickr.com/photos/glasser/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377406
Re: WebDAV proxies and locking
Posted by "C. Michael Pilato" <cm...@collab.net>.
Mark Phippard wrote:
> On Thu, Jul 30, 2009 at 4:59 PM, C. Michael Pilato<cm...@collab.net> wrote:
>
>> 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?
>
> FWIW, the lack of an ability to use some svnsync option to sync the
> locks also makes svnsync unsuitable for maintaining a backup
> repository or for using svnsync to migrate a repository to a newer
> version. I believe there are lots of users that use svnsync for both
> of these things today. But if a user also uses the lock feature, they
> either cannot use svnsync for this, or must live with the loss of the
> locks.
>
> Which is a roundabout way of saying I would be in favor of adding
> support for this to svnsync.
>
> I suppose a user in the WebDAV scenario could then use the
> post-lock/unlock/commit hooks to sync the locks? I am not sure how it
> would scale or be implemented, or whether there are existing ra calls
> that can be used to obtain/write the necessary information. But I
> think it would be the ideal if it could be done.
My hope is that the post-lock hook script on the master could call 'svnsync
lock', which would read the lock info from the master and (duh) copy it to
the slave(s). (There would also be an 'svnsync unlock', of course.) In
terms of the code to support this, yes, the svn_ra_lock() function would
need to grow a way to specify -- for each path you wish to lock -- a desired
lock token.
Not sure really how to transport this information across to the server,
though, in a scalable fashion. Can we change the format of the LOCK
request, or will that info just get lost in the mod_dav -> mod_dav_svn
translation? Do we specify it via a custom request header, or would get
sloppy too fast in multi-path LOCK requests? Do we continue our trend of
ditching WebDAV everywhere it gets in our way and use some sort of custom
POST or PUT request, or is that asking for trouble in some other way?
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377152
Re: WebDAV proxies and locking
Posted by km...@rockwellcollins.com.
Mark Phippard <ma...@gmail.com> wrote on 07/30/2009 04:11:53 PM:
> On Thu, Jul 30, 2009 at 4:59 PM, C. Michael Pilato<cm...@collab.net>
wrote:
>
> > 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?
>
> FWIW, the lack of an ability to use some svnsync option to sync the
> locks also makes svnsync unsuitable for maintaining a backup
> repository or for using svnsync to migrate a repository to a newer
> version. I believe there are lots of users that use svnsync for both
> of these things today. But if a user also uses the lock feature, they
> either cannot use svnsync for this, or must live with the loss of the
> locks.
>
> Which is a roundabout way of saying I would be in favor of adding
> support for this to svnsync.
I'm all in favor of adding support to this to svnsync, but would like
to point out that an svnadmin dump of a repository will also exclude
locks... It would be nice if locks were treated similarly there
as well.
Kevin R.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377149
Re: WebDAV proxies and locking
Posted by Mark Phippard <ma...@gmail.com>.
On Thu, Jul 30, 2009 at 4:59 PM, C. Michael Pilato<cm...@collab.net> wrote:
> 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?
FWIW, the lack of an ability to use some svnsync option to sync the
locks also makes svnsync unsuitable for maintaining a backup
repository or for using svnsync to migrate a repository to a newer
version. I believe there are lots of users that use svnsync for both
of these things today. But if a user also uses the lock feature, they
either cannot use svnsync for this, or must live with the loss of the
locks.
Which is a roundabout way of saying I would be in favor of adding
support for this to svnsync.
I suppose a user in the WebDAV scenario could then use the
post-lock/unlock/commit hooks to sync the locks? I am not sure how it
would scale or be implemented, or whether there are existing ra calls
that can be used to obtain/write the necessary information. But I
think it would be the ideal if it could be done.
--
Thanks
Mark Phippard
http://markphip.blogspot.com/
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2377147