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

Re: svnadmin lslocks ambiguity

From: Trent Fisher <trent.fisher_at_oracle.com>
Date: Wed, 15 Jan 2020 15:00:56 -0500

On 1/6/2020 1:42 PM, Daniel Shahaf wrote:
> Trent Fisher wrote on Mon, 06 Jan 2020 18:22 +00:00:
>> This seems like a bug in lslocks, why would it not list *all* the locks?
> If you run fsfs, it might be https://urldefense.proofpoint.com/v2/url?u=https-3A__subversion.apache.org_issue3750&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=ZbaTjKb7ivmk5rbWkuwu4Mqvrh_gmetmbEk2XMe0cVs&m=HvcvPbSptrAq78THvePuzylhdDLG4ABfI9Y5NXg15ac&s=c8ls12Aj8kxq6gQ4jXAltM3ipA4nFCLssJk0XndlTuU&e= .

So, from that, it sounds like copying a repository could result in the
locks data structures in FSFS becoming inconsistent?  This would make
sense as I am working with an rsync'ed copy of a repository (though the
bug seems to be saying that even hotcopy can end up with this problem)

Is there a way to either fix the lock database to be consistent, or just
to clear it?
Received on 2020-01-15 21:01:13 CET

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.