Where are you quoting that from? I don't see it on the issue.
jmountifield: svnadmin is not a client; in 'load' it interacts directly
with the underlying filesystem, while bypassing all the other layers
(including hooks). The locks are a first-class object in the
filesystem, though, rather than some artifact of higher layers.
[ Bert, if you haven't, could you please point to this thread from the
issue where jmountifield's comment is on? Thanks ]
Bert Huijben wrote on Fri, Jul 15, 2011 at 17:20:20 +0200:
>
>
> > -----Original Message-----
> > From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> > Sent: vrijdag 15 juli 2011 17:04
> > To: Noorul Islam K M
> > Cc: Subversion
> > Subject: Re: [PATCH] Issue 3942 - Provide new subcommand on svnadmin to
> > create a lock
> >
> > On 07/15/2011 08:58 AM, Noorul Islam K M wrote:
> > > As first step I implemented the following syntax.
> > >
> > > svnadmin lock REPOS PATH USERNAME COMMENT-FILE
> > >
> > > I will add the optional TOKEN argument later. I hope I am progressing in
> > > the right direction.
> >
> > I've not reviewed this work, but you might also consider allowing this
> > subcommand to accept --bypass-hooks, too.
>
> To keep the information on this thread I quote a bit of information that was just added to this issue:
>
> ------- Additional comments from jmountifield_at_tigris.org Fri Jul 15 07:01:25 -0700 2011 -------
>
> Replicating the locks to the slave server, even with the right lock token value,
> still leaves us with some issues in the master/slave configuration. The
> following is based on local testing with svn, version 1.6.12 (r955767).
>
> Once a slave repository has locks present you cannot keep that slave up to date.
> This is true with both `svnsync sync` and `svnadmin load`.
>
> With svnsync the reasons are somewhat obvious. The process looks like a normal
> commit, and commits are blocked by locks. So, unless there's some way to change
> the locking behaviour for svnsync specifically, I can't see a workaround here.
>
> More surprisingly the same is true with `svnadmin load`. This strikes me as
> somewhat odd as these locks are definitely client layer, and svnadmin isn't a
> client, right?. Why should svnadmin load respect the locks?
>
> When trying to `svnadmin load` into a repository that has a lock on a path
> touched by that load I get the following message:
>
> mounty_at_laptop$ svnadmin load /tmp/lock-test < /tmp/lock-test.5.dmp
> <<< Started new transaction, based on original revision 5
> * editing path : trunk/foo.c ... done.
> svnadmin: Cannot verify lock on path '/trunk/foo.c'; no username available
>
>
> So, to sum up; If we replicate locks to the slave in the scenario described
> above, we effectively make it impossible to keep the slave in sync with the
> master, using the current options available.
>
> Others have also asked that the svn dump format be able to capture lock tokens.
> In this scenario `svnadmin load` will need to be able to operate around the
> locks to enable loading of incremental dump files, where one or more dump files
> describe a lock token.
>
> -----------------------------------------------
> Bert
>
>
Received on 2011-07-15 17:36:48 CEST