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

RE: svn commit: r1667258 - in /subversion/trunk/subversion/libsvn_wc: conflicts.c conflicts.h merge.c props.c update_editor.c

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 16 Apr 2015 12:02:46 +0200

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: donderdag 16 april 2015 00:15
> To: dev_at_subversion.apache.org
> Subject: Re: svn commit: r1667258 - in
/subversion/trunk/subversion/libsvn_wc:
> conflicts.c conflicts.h merge.c props.c update_editor.c
>
> On Tue, Mar 17, 2015 at 10:55:46AM -0000, rhuijben_at_apache.org wrote:
> > Author: rhuijben
> > Date: Tue Mar 17 10:55:45 2015
> > New Revision: 1667258
> >
> > URL: http://svn.apache.org/r1667258
> > Log:
> > Avoid a db operation for each property conflict in some invocations of
> > the interactive conflict resolver.
>
> > Modified: subversion/trunk/subversion/libsvn_wc/update_editor.c
> > URL:
>
http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/update_e
> ditor.c?rev=1667258&r1=1667257&r2=1667258&view=diff
> >
> ================================================================
> ==============
> > --- subversion/trunk/subversion/libsvn_wc/update_editor.c (original)
> > +++ subversion/trunk/subversion/libsvn_wc/update_editor.c Tue Mar 17
> 10:55:45 2015
>
> Are we sure the hard-coded node kinds (svn_node_dir, svn_node_file)
> below are always correct? These are supposed to represent the node
> kind of the tree conflict victim, which is not necessarily the same
> as the server thinks it should be.

Yes.

Tree conflict detection happens in <add/open>_<directory/file>() and this
doesn't invoke the conflict resolver callback.

In the cases where we do invoke the resolver we just read and pass the
actual kind, or we just process the BASE kind where we know it is not
different from what there is in the working copy(or we already raised a tree
conflict before).

BTW: libsvn_client doesn't use this callback infrastructure for anything but
collecting the paths that are conflicted. The actual resolving happens via
the standard conflict resolving code, unless you implement your own update
invocation via deprecated libsvn_wc functions.

This also explains why we don't call the callback for tree conflicts: nobody
is really using this, and old versions didn't call into the callback either.

        Bert
Received on 2015-04-16 12:04:52 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.