Daniel Berlin wrote:
>
> Right now, the feature is *not* designed to be cleanup-safe, nor would
> such a thing be fast. It is *just as unsafe as killing the client*.
No, it's not just as unsafe as killing the client. "svn commit" leaves locks,
as you pointed out, but the cancellation mechanism avoids leaving locks from
other commands e.g. "svn update" and is valuable because of it.
> I'm simply arguing that it's not the best solution for the command line
> client to use such an interface, until it exists, when a simpler method
> with the same safety properties, much greater interactivity, and is more
> intuitive to users, exists.
I agree that the ability to quit (reasonably quickly) is important, and that
the command-line app should use a simple exit if the cancellation mechanism
doesn't exit quickly enough.
Some users will want "svn" to do as much clean-up as it can, and would consider
it fair to have to wait a while (comparable with the time the command has taken
up to that point), but if this is going to take more than a second or so there
should be some indication that "svn" has received the interrupt and is cleaning up.
I support the concept that your (Daniel's) patch embodies: the first interrupt
makes Subversion try to exit nicely, and a subsequent one forces an immediate exit.
As for the details of operation, there are many possible variations (of number
of interrupts required, at which stages messages are printed, and potentially
minimum and maximum times between stages). I'd like the scheme to be aas
simple as possible except that the user should be informed of the progress of
the cancellation attempt so that he/she can make an informed choice of whether
to force a hard exit. So I suggest:
* The first interrupt is noted as usual.
* When the normal code path later checks and notices the request, it prints
a message indicating that the operation is aborted and it is cleaning up. This
provides confirmation that the cancellation request is taking effect, and
enables the user to better judge whether to wait for Subversion to finish what
it is doing.
* A second interrupt (whether before or after the app notices the request)
causes an immediate exit.
If the user hits Ctrl-C and doesn't see the "Aborted; cleaning up..." message
within what she considers to be a reasonable time, or does see it but the app
still doesn't finish within a reasonable time after that, she can choose to
press Ctrl-C again and the process will quit immediately.
> IMHO, it would also make your design goals for such a cleanup-safe
> cancellation mechanism that much easier and cleaner.
[...]
Yup, that's nice.
Greg Hudson wrote:
>> Why can't we clean up those locks [left by an interrupted commit]?
Daniel Berlin wrote:
> We handle it like any other error that occurs during commit/whatever.
> Anything else would require restructuring the wc code in very
> significant ways, AFAIK.
Maybe, but it would be good if somebody would investigate, in case it turns out
not to be so hard.
> Also, doing such cleaning up would itself takes a long time on a gcc
> working copy, since it has a ton of directories. I imagine if we used
> fcntl locking instead of lock files, we could just go away and the
> kernel/libc would clean up after us.
There's an idea worth investigating: can we make a portable locking API whose
implementation uses the system's locking facilites (fcntl, etc.) where
available and plain files otherwise?
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 14 13:41:29 2006