Julian Foad wrote on Thu, Apr 05, 2012 at 16:26:15 +0100: > How would an admin arrange for svnsync to synchronize locks > (reserved-checkout locks, that is)? >
http://s.apache.org/xy-problem. Perhaps mod_dav_svn in slave/proxy mode should learn to query the master for the existence of locks? > > I was talking to Philip and he mentioned that he'd been thinking about > this. It seems to us that the only way available currently is for > post-[un]lock on the master to rsync the whole 'locks' directory to > the slave. (That's for FSFS; no idea if there's an equivalent for > BDB.) That doesn't seem satisfactory, for several reasons. One issue > is it isn't guaranteed to happen in the right order relative to > commits. > > In terms of *preventing* a user committing to a locked file without > holding the lock, you don't need the locks to be present on the slave, > of course, because it's the master not the slave that will process > a commit. But if we don't sync locks onto the slave, then users > checking out and updating from the slave will not see the correct set > of locks, which is unhelpful. > > Could we teach svnsync to sync locks? > > > If we did have a way to sync locks, there would then be locks on the > slave, and how would "svnsync sync" then make commits? I can't think > how it could know what lock tokens it should provide with the commit; > the master kept no record of them, nor even of the fact that such > locks existed on the master at that earlier point in time. I suppose > svnsync would have to make its commit to the slave in a way that > bypasses all lock checking. Or maybe there are ways we could make it > supply the right list of lock tokens, but I can't think of a way. > Bypassing all locks should be fine in this scenario. > > > Thoughts? > > - Julian >
