We sould factor catching of IO exceptions into applyToWorking to
reduce duplication, now that we do it uniformly whenever we call it.
We also sometimes call applyToWorking inside withSignalsBlocked but
not uniformly. We do it for clone (when conflicts are marked),
unrevert, mark-conflicts, and for pull and apply via
standardApplyPatches. But not for rollback, revert, unrecord,
replace, rebase suspend/unsuspend.
I fail to see the pattern here.
The apparent rationale for withSignalsBlocked is that an interrupt
(user hitting Ctrl-C) would mean that changes may be applied
partially, leaving the working tree in an inconsistent state. Makes
sense but again I can't see a reason not to do this uniformly, which
means we can also factor it into applyToWorking.
The following patch sent by Ben Franksen <firstname.lastname@example.org> updated issue issue2626 with
* resolve issue2626: treat applyToWorking more uniformly
This factors catching IO errors into applyToWorking with a generic error
message that should fit all use cases. In case of the 'convert darcs-2'
command, the extra clarification that suggests to use --no-workingdir has
been removed as I find it misleading and cannot see how that could actually
help: we have created the whole working tree ourselves, so if applying the
patches fails something really weird (like another process interfering with
the working tree) must be going on.
It also adds a number of withSignalsBlocked to wrap the calls to
applyToWorking where they were missing. Where possible, the scope of actions
under withSignalsBlocked is extended to include finalization and/or updating
the pending patch. This has previously been the case for some commands but
not all of them.