Changed the title so that roundup (hopefully) recognizes the issue number.

I think there are two cases to consider here:

If the lock is only temporarily unavailable, the proposed solution is nice.

But if the lock is unavailable due to some error or due to a
misconfiguration, I think it is not realistic to expect the user to keep
darcs hanging in the loop all the time it takes to resolve any
underlying issue.

So: yes, this is a partial solution but we should also offer a way to
save the current selection to a file which can then be read in by a
subsequent record. Similar for other commands that require patch selection.

1/ the patch fix the problem describe in issue
2/ I would have a look for an improvement and offer to user the choice 
to save selection in file. And then a command to reply from file.

1/ the patch fix the problem describe in issue2327
2/ I would have a look for an improvement and offer to user the choice 
to save selection in file. And then a command to reply from file.

Re: 1/ the patch fix the problem describe in issue2327

The repo locking code looks as if it does not "instantly give up" but
rather tries to lock for a number of times (30) using a delay of 2
seconds in between. That means it should try to get the lock for one
minute before giving up. Is that consistent with your experience?

Note: I am minded to accept the patch, just want to understand the
issues involved a bit better.

BTW, what was the reason for the failed lock in your case?

Converted this to a darcs patch.

BTW: you can use 'darcs send -O' to create darcs patch bundle with an
auto-generated file name, then attach the file to an email and send it with
your favourite mail program.

1 patch for repository http://darcs.net/screened:

patch b30f729b3499d31e1beb461cec229f4bf5e8c4ee
Author: Ben Franksen <benjamin.franksen@helmholtz-berlin.de>
Date:   Sat Jun 13 23:30:53 CEST 2015
  * resolve issue2327: ask user to keep trying if locking fails

Attachments

• patch-preview.txt
• resolve-issue2327_-ask-user-to-keep-trying-if-locking-fails.dpatch
• unnamed

Seems reasonable. One slight worry is that could cause problems for 
scripts that weren't expecting darcs to ask for user input at this 
point and would have preferred it to just fail. But I think that's 
marginal.

What about using the --(no-)force option to allow a script to control 
the behaviour of the command ?

or creating a new option --no-asking ?

Adding an extra option means such scripts have to be changed to add the
new option. If they have to do this, they can as well change the call to

 yes|darcs <args>

Given that each additional option makes the UI more complex, I think the
net win is negative.

However: we could decide to ask the user only if --interactive is in
effect (or rather, if isInteractive returns True). This would cover all
scenarios where the user gets hurt by darcs giving up, while not
punishing scripts, at least not those that turn interactivity off
(either explicity or implicitly).

I'm marking this as accepted as the current situation is good enough, but 
feel free to add a followup to either this patch or as a fresh one.

It seems difficult to add access to /"isInteractive" /because this 
function needs the list of flags as argument. But options list are not 
accessible in the arguments.

I don't want to destabilize the code by adding new argument to manage 
/"isInteractive"

/I'd rather to stay with the current patch//and I stop to investigate on 
this issue.


Le 22/06/2015 22:04, Ben Franksen a écrit :
> Ben Franksen <benjamin.franksen@helmholtz-berlin.de> added the comment:
>
> Adding an extra option means such scripts have to be changed to add the
> new option. If they have to do this, they can as well change the call to
>
>   yes|darcs <args>
>
> Given that each additional option makes the UI more complex, I think the
> net win is negative.
>
> However: we could decide to ask the user only if --interactive is in
> effect (or rather, if isInteractive returns True). This would cover all
> scenarios where the user gets hurt by darcs giving up, while not
> punishing scripts, at least not those that turn interactivity off
> (either explicity or implicitly).
>
> __________________________________
> Darcs bug tracker <bugs@darcs.net>
> <http://bugs.darcs.net/patch1333>
> __________________________________

Attachments

• unnamed

Yes, the thought occurred to me, too. Anyway the correct solution would
be to evaluate isInteractive in the command implementations
(Darcs.UI.Command.*) and pass on a boolean flag (or perhaps a new Type
in Darcs.Repository.Flags) to the Repository functions. That would
indeed mean many, many changes with small benefit.