'The Three Meanings of "Lock"' += svn:sync-lock ?

C. Michael Pilato cmpilato at red-bean.com
Mon Oct 2 09:06:14 CDT 2017


It only took me a year-and-a-half, but I committed a modified version of
Daniel's patch today.  (Now it's "The Many Meanings of 'Lock'. :-))

On Thu, Mar 17, 2016 at 4:09 PM, Daniel Shahaf <danielsh at apache.org> wrote:

> Pavel Lyalyakin wrote on Thu, Mar 17, 2016 at 18:36:53 +0300:
> > Hello,
> >
> > On Wed, Mar 9, 2016 at 4:24 PM, Daniel Shahaf <danielsh at apache.org>
> wrote:
> >
> > > Concerning the 'The Three Meanings of "Lock"' box:
> > > .
> > >
> > > http://svnbook.red-bean.com/nightly/en/svn.advanced.
> locking.html#svn.advanced.locking.meanings
> > > .
> > > Should that box mention svnsync locks as well?
> > >
> > > (These are the svn_ra__get_operational_lock() locks that svnsync takes
> > > using the svn:sync-lock revprop, exposed in the UI through the
> > > --disable-locks/--steal-lock options to 'svnsync sync'.  Note 'svnrdump
> > > load' also uses this kind of operational lock.)
> > >
> >
> > I doubt that the revprop-based lock `svnsync` or `svnrdump` places is
> worth
> > mentioning in the 'The Three Meanings of "Lock"' section.
> >
> > `svnsync` and `svnrdump` place `svn:sync-lock` and `svn:rdump-lock`
> > revprops to revision 0 and it's an implementation detail, not a real
> > concept.
>
> That's a fair point, but on the other hand, this particular
> implementation detail is user-facing, via the --steal-lock option and
> the following error message:
>
>     % svnsync sync file://$PWD/{r,r2}
>     Failed to get lock on destination repos, currently held by
> 'hostname:84a4136e-a3fb-4f2b-8b52-9502a886ff3a'
>>     Failed to get lock on destination repos, currently held by
> 'hostname:84a4136e-a3fb-4f2b-8b52-9502a886ff3a'
>     svnsync: E000022: Couldn't get lock on destination repos after 10
> attempts
>     zsh: exit 1     svnsync sync file://$PWD/{r,r2}
>
> > It's just how it works in Subversion 1.9 and older versions.
> > Thinking about it, this could easily change in the future, should
> `svnsync`
> > or `svnrdump` stop placing such kind of locks.
> >
>
> If it changes in the future, we can update the book at that time to
> document the new behaviour...
>
> Thanks for the review,
>
> Daniel
>
> _______________________________________________
> svnbook-dev mailing list
> svnbook-dev at red-bean.com
> http://www.red-bean.com/mailman/listinfo/svnbook-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.red-bean.com/pipermail/svnbook-dev/attachments/20171002/2a9a3a5e/attachment.html>


More information about the svnbook-dev mailing list