On Mon, Feb 18, 2013 at 12:32:09PM -0500, Mark Phippard wrote:
> On Mon, Feb 18, 2013 at 12:18 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> > On Mon, Feb 18, 2013 at 06:02:40PM +0100, Stefan Sperling wrote:
> >> On Mon, Feb 18, 2013 at 11:50:51AM -0500, Mark Phippard wrote:
> >> > I just did a merge using current trunk. There were a lot of text and
> >> > tree conflicts. I noticed it does not start resolving them until the
> >> > end now, which is expected. However, one thing I could not do was
> >> > postpone all conflicts. I used the 's' option and saw that option 'q'
> >> > is supposed to do this but I still had to enter 'p' or 'q' for every
> >> > conflict.
> >> >
> >> > I assume this is a bug?
> >>
> >> The new "q" option was added only very recently, in r1440421.
> >>
> >> What seems strange is that the code committed in that revision is mixing
> >> up enum types. It is assigning values of type svn_cl__accept_t to a
> >> constant of type svn_wc_conflict_choice_t. Not sure if that explains
> >> the problem you are seeing but it seems the code isn't quite correct.
> >
> > Perhaps r1447398 helps? It cleans up the issue I described above.
>
> I still see the same behavior.
>
> Also, not sure if this intentional, but just hitting Enter also does Postpone.
Typing 'enter' also postpones here.
But answering 'q' works for me before and after r1447398, on OpenBSD.
(Except that typing backspace doesn't erase characters at the prompt :-( )
Which platform are you on? Windows?
Is it possible that the new code added for prompting on the terminal
is responsible for this?
Received on 2013-02-18 18:45:21 CET