[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: [PATCH] Issue 3942 - Provide new subcommand on svnadmin to create a lock

From: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 15 Jul 2011 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.
> >
> >
> > 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.

Received on 2011-07-15 17:20:59 CEST

This is an archived mail posted to the Subversion Dev mailing list.