How would an admin arrange for svnsync to synchronize locks (reserved-checkout locks, that is)?
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
