From users-return-15838-apmail-subversion-users-archive=subversion.apache.org@subversion.apache.org Wed Aug 15 11:36:01 2012 Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 941D39C99 for ; Wed, 15 Aug 2012 11:36:01 +0000 (UTC) Received: (qmail 55966 invoked by uid 500); 15 Aug 2012 11:36:00 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 55630 invoked by uid 500); 15 Aug 2012 11:35:57 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 55595 invoked by uid 99); 15 Aug 2012 11:35:55 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 11:35:55 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 209.85.215.171 is neither permitted nor denied by domain of codematters@ntlworld.com) Received: from [209.85.215.171] (HELO mail-ey0-f171.google.com) (209.85.215.171) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 15 Aug 2012 11:35:47 +0000 Received: by eaah11 with SMTP id h11so702135eaa.16 for ; Wed, 15 Aug 2012 04:35:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:x-proxyuser-ip:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version:content-type :x-gm-message-state; bh=ERhsDv7T3TcQqI3+zHD8cXR0H2FYKFUf4JIuOcPNaps=; b=dRQ2cY1zR1gVtxbbjPRj6KD8gsQHy9pchDY/dV5OxLHeHsvO2oXdLv5SpE3wxh9Xor f/Qp4XqQyjwMAD7XLtIeqT9fRBOaPTMe08EOVMRnbEN+/Z/6oFQiu/RK2ZoliCl3e+EG +iKPgdngbnda2RV7ec73Ki0vW0q/+ON/F1C0hLDLh4CNCV2Tw/APnUCGg8xAEn5K2Qvh bhW7c72JIckTOq3Vvwx6T1sLQjSW5k2DO3+HTA/nQuGma/1ewYDnIvBosgqGDCiA1UNk lLSbM//FGfCmmfyKhiBleoFCswU3zMMMAWoQy1kAzvu6PDJRDzdJ4x1svy4jnmu36EaZ eaDQ== Received: by 10.14.215.197 with SMTP id e45mr23780880eep.36.1345030526780; Wed, 15 Aug 2012 04:35:26 -0700 (PDT) Received: from (know-mailgateway-1.server.virginmedia.net. [62.254.26.97]) by mx.google.com with ESMTPS id z6sm3380258eeo.6.2012.08.15.04.35.25 (version=SSLv3 cipher=OTHER); Wed, 15 Aug 2012 04:35:25 -0700 (PDT) Sender: MARTIN PHILIP Received: from source ([86.17.224.110]) by smtp.virginmedia.com with SMTP; Wed, 15 Aug 2012 11:35:25 +0000 (GMT) X-ProxyUser-IP: 86.17.224.110 Received: by cpc2-farn6-0-0-cust109.6-2.cable.virginmedia.com (Postfix, from userid 1000) id 5BBD7361A5; Wed, 15 Aug 2012 12:35:24 +0100 (BST) From: Philip Martin To: "rog7993\@web.de" Cc: users@subversion.apache.org Subject: Re: files in db/locks References: <5023F0F0.1040302@web.de> <20120810222930.GA22411@tarsus.local2> <502B7CB5.3090202@web.de> Date: Wed, 15 Aug 2012 12:35:24 +0100 In-Reply-To: <502B7CB5.3090202@web.de> (rog's message of "Wed, 15 Aug 2012 12:40:53 +0200") Message-ID: <87zk5w8k1v.fsf@stat.home.lan> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Gm-Message-State: ALoCoQmA3j5CnUx/Rm3HvlsbkXEUGGZP0F+KYeB3oHgQ4ZZQwx6NxzJEgDY6c+zkdhK93iqqN9HQ "rog7993@web.de" writes: > Hello Daniel, > > Am 11.08.2012 00:29, schrieb Daniel Shahaf: >> If you lock /foo/bar/baz then db/locks/${hash} files are created for each of / , >> /foo , /foo/bar . >> >> Consequently, if (a) there are no locks in the repository, and (b) no >> locks are being added or deleted (eg: the server is in read-only mode), >> then it ought to be safe to remove all those hashes. > > Thanks for the explanation. But why do I still see these files > although all locks in this repository have have been removed some > weeks ago? Is this intended or a misbehaviour of the subversion > server? There was a bug that caused unlock to leave the files: http://subversion.tigris.org/issues/show_bug.cgi?id=3667 It is fixed in 1.6.13 but the files will remain until a suitable new lock/unlock causes them to be deleted. -- Philip