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 70C71C938 for ; Sat, 2 Jun 2012 20:02:14 +0000 (UTC) Received: (qmail 61915 invoked by uid 500); 2 Jun 2012 20:02:12 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 61873 invoked by uid 500); 2 Jun 2012 20:02:12 -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 61864 invoked by uid 99); 2 Jun 2012 20:02:12 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jun 2012 20:02:12 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [217.140.74.2] (HELO continuum.iocl.org) (217.140.74.2) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 02 Jun 2012 20:02:07 +0000 Received: (from krey@localhost) by continuum.iocl.org (8.11.3/8.9.3) id q52K1gI24342; Sat, 2 Jun 2012 22:01:42 +0200 Date: Sat, 2 Jun 2012 22:01:42 +0200 From: Andreas Krey To: "Michael P. Reilly" , users@subversion.apache.org Subject: Re: Can't kill svn Message-ID: <20120602200142.GK10680@inner.h.iocl.org> References: <20120601191347.GF10680@inner.h.iocl.org> <20120602091416.GA6277@ted.stsp.name> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120602091416.GA6277@ted.stsp.name> User-Agent: Mutt/1.4.2.1i X-message-flag: What did you expect to see here? X-Virus-Checked: Checked by ClamAV on apache.org On Sat, 02 Jun 2012 11:14:16 +0000, Stefan Sperling wrote: ... > Some signals never have an immediate effect in Subversion. > Subversion handles signals gracefully at defined points to ensure state > is cleaned up properly. Hanging more than a minute isn't exactly what I consider 'graceful'. > When the signal is received, a flag is set that > is checked next time Subversion invokes the cancellation handler which > then cleans up state and causes an exit. No, it doesn't. With 1.7.4: | a:cc-svn-7 andreaskrey$ svn17 up -r85321 | Updating '.': | D tools | U ivy.xml | U src/.... | U . | | Fetching external item into 'ioc': | D moda/CHANGES | U moda/h/... (redacted output lists) | U moda/src/... | ^Csvn: E200015: Caught signal Ok, it did terminate, and fast. But there is no 'graceful' in here: | a:cc-svn-7 andreaskrey$ svn17 up -r85321 | Updating '.': | | Fetching external item into 'ioc': | svn: warning: W155004: Working copy '/Users/andreaskrey/cc-svn-7/ioc' locked. ...and that situation persists. "graceful" != "requiring manual intervention, as with 'svn cleanup'". I only see the point of an arbitrary wait when svn then at least leaves the sandbox in a state that doesn't require cleanup. Incidentally, I only found that because I wanted to see if there is still the cascade of | svn: warning: Error handling externals definition for 'moda': | svn: warning: Caught signal | svn: warning: Error handling externals definition for 'modb': | svn: warning: Caught signal | svn: warning: Error handling externals definition for 'etc': | svn: warning: Caught signal | svn: warning: Error handling externals definition for 'ant-scripts': | svn: warning: Caught signal for a single ^C. Instead the wc is borked with: | svn: Failed to add directory 'tools': an unversioned directory of the same name already exists and a spurious conflict on svn:externals on the root (this with 1.6.6). (svn is 1.6.6, svn17 is 1.7.4.) Andreas -- "Totally trivial. Famous last words." From: Linus Torvalds Date: Fri, 22 Jan 2010 07:29:21 -0800