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
>
Received on 2012-04-05 19:41:38 CEST