RE: svn commit: r1357313 - in /subversion/trunk/subversion/svn: cl.h notify.c update-cmd.c

> -----Original Message-----
> From: Paul Burba [mailto:ptburba_at_gmail.com]
> Sent: woensdag 5 september 2012 23:25
> To: Julian Foad
> Cc: Stefan Sperling; dev_at_subversion.apache.org
> Subject: Re: svn commit: r1357313 - in /subversion/trunk/subversion/svn:
> cl.h notify.c update-cmd.c
>
> On Wed, Sep 5, 2012 at 11:11 AM, Julian Foad
> <julianfoad_at_btopenworld.com> wrote:
> > Stefan Sperling wrote:
> >
> >> On Tue, Sep 04, 2012 at 03:01:22PM -0400, Paul Burba wrote:
> >>> I just noticed that this causes a segfault when updating with
> >>> the quiet option:
> >>
> >> Thanks for digging into this and explaining the problem, Paul.
> >>
> >> I cannot think of a better way to fix this than recording in
> >> opt_state whether the notifier is being used. That way we
> >> have a way of telling whether it is safe to ask the notifier
> >> for a list of conflicted paths.

So now -q changes the behavior of the conflict resolver?

Sounds like an ugly hack, to me.

I think we should install an old style interactive conflict handler to collect the conflicted paths and make it jusr postpone all conflicts. That will give us the list for resolving after the operation.

Another option is making the true notifications optional in the notification handler and always installing it just to collect the conflicted paths, but installing a conflict handler for that seems like a cleaner solution to me?

The conflict handler might be extendable to handle --accept theirs-full and some others directly, while postponing the conflicts that must be handled interactive later.

        Bert
Received on 2012-09-06 10:25:49 CEST