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:cmpil...@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 jmountifi...@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@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 > >
