Re: svn commit: r1354029 - in /subversion/trunk/subversion/libsvn_client: merge.c switch.c update.c

[Greg Stein <gs...@gmail.com>]

On Tue, Jun 26, 2012 at 10:21 AM,  <st...@apache.org> wrote:
> Author: stsp
> Date: Tue Jun 26 14:21:18 2012
> New Revision: 1354029
>
> URL: http://svn.apache.org/viewvc?rev=1354029&view=rev
> Log:
> Remove some redundant local variables. We're now effectively always postponing
> conflict resolution until after an update/switch/merge has completed.
>
> The intent of resolving conflicts during an operation for 1.5 API users
> won't work anyway, since our backwards compat wrappers will always pass
> a 1.7-style conflict_func2 which wraps a 1.5 conflict_func.

I'm unclear on this. It seems that if no conflict2_func is passed,
then we can pass a wrapper for 1.7-style resolution during the
operation. ie. stop hard-coding NULL and possibly provide a wrapper
for the 1.5 API.

(not sure what we'd do for 1.6 and 1.7, but it seems pretty clear we
could support 1.5 and before)

>...

Cheers,
-g

Re: svn commit: r1354029 - in /subversion/trunk/subversion/libsvn_client: merge.c switch.c update.c

[Stefan Sperling <st...@elego.de>]

On Tue, Jun 26, 2012 at 06:00:06PM +0200, Bert Huijben wrote:
> > > The intent of resolving conflicts during an operation for 1.5 API users
> > > won't work anyway, since our backwards compat wrappers will always pass
> > > a 1.7-style conflict_func2 which wraps a 1.5 conflict_func.
> > 
> > I'm unclear on this. It seems that if no conflict2_func is passed,
> > then we can pass a wrapper for 1.7-style resolution during the
> > operation. ie. stop hard-coding NULL and possibly provide a wrapper
> > for the 1.5 API.
> > 
> > (not sure what we'd do for 1.6 and 1.7, but it seems pretty clear we
> > could support 1.5 and before)
> 
> For the libsvn_client api we already wrap the 1.7 api, by setting a default
> wrapper in the svn_client_ctx_t that calls the conflict_func. 
> (Before 1.5 we didn't use any conflict callbacks)
> 
> I think the behavior difference Stephan talks about is that he can ignore an
> older style conflict handler without a newer one.

Yes, it seems with our libsvn_client APIs callers will always pass in a
conflict_func2 even if a 1.5 API users passes a conflict_func.
So we cannot detect what API the caller is really using by inspecting
the conflict_func2 pointer.

And even if we could, it seems that trying to keep the exact 1.5
behaviour for 1.5 API users is more trouble than it is worth. It's not
as if the new behaviour will fundamentally break things. The callback will
just be invoked at a different time. And if we're willing to expose code
compiled against the 1.7 API to this, why treat code compiled against 1.5
differently?

RE: svn commit: r1354029 - in /subversion/trunk/subversion/libsvn_client: merge.c switch.c update.c

[Bert Huijben <be...@qqmail.nl>]

> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: dinsdag 26 juni 2012 17:48
> To: dev@subversion.apache.org
> Subject: Re: svn commit: r1354029 - in
> /subversion/trunk/subversion/libsvn_client: merge.c switch.c update.c
> 
> On Tue, Jun 26, 2012 at 10:21 AM,  <st...@apache.org> wrote:
> > Author: stsp
> > Date: Tue Jun 26 14:21:18 2012
> > New Revision: 1354029
> >
> > URL: http://svn.apache.org/viewvc?rev=1354029&view=rev
> > Log:
> > Remove some redundant local variables. We're now effectively always
> postponing
> > conflict resolution until after an update/switch/merge has completed.
> >
> > The intent of resolving conflicts during an operation for 1.5 API users
> > won't work anyway, since our backwards compat wrappers will always pass
> > a 1.7-style conflict_func2 which wraps a 1.5 conflict_func.
> 
> I'm unclear on this. It seems that if no conflict2_func is passed,
> then we can pass a wrapper for 1.7-style resolution during the
> operation. ie. stop hard-coding NULL and possibly provide a wrapper
> for the 1.5 API.
> 
> (not sure what we'd do for 1.6 and 1.7, but it seems pretty clear we
> could support 1.5 and before)

For the libsvn_client api we already wrap the 1.7 api, by setting a default
wrapper in the svn_client_ctx_t that calls the conflict_func. 
(Before 1.5 we didn't use any conflict callbacks)

I think the behavior difference Stephan talks about is that he can ignore an
older style conflict handler without a newer one.

	Bert
> 
> >...
> 
> Cheers,
> -g