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

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

From: Bert Huijben <bert_at_qqmail.nl>
Date: Tue, 26 Jun 2012 18:00:06 +0200

> -----Original Message-----
> From: Greg Stein [mailto:gstein_at_gmail.com]
> Sent: dinsdag 26 juni 2012 17:48
> To: dev_at_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, <stsp_at_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
Received on 2012-06-26 18:01:07 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.