C. Michael Pilato wrote on Fri, Jul 15, 2011 at 13:17:13 -0400: > On 07/15/2011 12:16 PM, Daniel Shahaf wrote: > > If svnsync presents the lock token that's present on the master, and > > hopefully the slave checks locks against the master during commit, the > > commit is going to work isn't it? > > I considered this, but the FS code checks not only the lock tokens, but also > that they match their registered owners. The problem is that it checks > against but a single owner -- the authenticated username associated with the > committing process. > > Alternatively, I've considered a mod_dav_svn directive (say, > "SVNDisableTxnLockCheck on") which could be set on the slave to indicate > that when the slave calls svn_fs_begin_txn2(), it does so without the > SVN_FS_TXN_CHECK_LOCKS flag, effectively disabling on-the-fly lock checks. > I'm not sure if that's sufficient to disable *all* lock checks, though. > Haven't gotten that deeply into the code yet.
Two thoughts: * 'svnadmin load' could learn to not pass the flag you mention, in order to address one of James's issues. * Perhaps we need a boolean configuration option for the FS library saying "You are the slave/mirror/replica of something else, and higher layers are handling the mirroring"? This will enable the FS understand the locks it has are advisory, not normative; and will also play to Mark's point of "writing to the slave's FS via a non-mod_dav_svn RA layer".
