[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: svn commit: r1351822 -

From: Bert Huijben <bert_at_vmoo.com>
Date: Wed, 20 Jun 2012 03:13:51 -0700

 /subversion/trunk/subversion/libsvn_client/switch.c
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit

Another option would be to make svn choose the new behavior by not
passing a conflict resolver the old way.

And maybe you couls even take this one one step further by also calling
the new standalone conflict resolver from svn. (Triggered by some
notification?)

Bert Huijben (Cell phone)
From: Stefan Sperling
Sent: 20-6-2012 12:00
To: Greg Stein
Cc: dev_at_subversion.apache.org
Subject: Re: svn commit: r1351822
- /subversion/trunk/subversion/libsvn_client/switch.c
On Wed, Jun 20, 2012 at 01:54:29AM -0400, Greg Stein wrote:
> On Jun 19, 2012 9:52 PM, <stsp_at_apache.org> wrote:
> >...
> > + if (resolve_conflicts_post_switch)
> > + {
> > + /* Remove the conflict resolution callback from the client context.
> > + * We invoke it after of the switch instead of during the switch.
> */
> > + conflict_func2 = ctx->conflict_func2;
> > + conflict_baton2 = ctx->conflict_baton2;
> > + ctx->conflict_func2 = NULL;
> > + ctx->conflict_baton2 = NULL;
> > + }
>
> This feels like a terrible hack, of the worst kind.
>
> The caller gives you a client context, and you change it on them. It's
> theirs. Not yours to redefine.
> Even worse, you never restore it! The context is now damaged because you
> monkeyed with it. The context is NOT a single-use structure. It can live
> for hours, over multiple operations, by design. But the above hack destroys
> it.
>
> I think you need to find a new approach.

Agreed, plus I'm not happy with changing the behaviour for 1.7 API users.
Keeping 1.5 behaviour the same while changing behaviour of already released
1.7 APIs is... inconsistent.

Maybe we need a new-in-1.8 conflict_func3 that has different invocation
rules than conflict_func2, but otherwise the same signature (unless we
decide to change it before release for some reason)? Would that be better?
Received on 2012-06-20 12:14:28 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.