Re: Can't kill svn

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 <torvalds@*.org>
Date: Fri, 22 Jan 2010 07:29:21 -0800