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".
Received on 2011-07-15 19:29:48 CEST