On 04/05/2012 11:26 AM, Julian Foad wrote:
> 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.
See http://subversion.tigris.org/issues/show_bug.cgi?id=3457 for earlier
manifestations of these thoughts and links to possibly to some more
complications.
--
C. Michael Pilato <cmpilato_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2012-04-05 18:19:51 CEST