> -----Original Message-----
> From: Philip Martin [mailto:[email protected]]
> Sent: donderdag 7 juli 2011 16:46
> To: Bert Huijben
> Cc: [email protected]; [email protected]
> Subject: Re: [Issue 3951] serf fail prop_tests.py 3 with 1.6 mod_dav_svn
> 
> "Bert Huijben" <[email protected]> writes:
> 
> >> -----Original Message-----
> >> From: [email protected] [mailto:[email protected]]
> >> Sent: donderdag 7 juli 2011 12:56
> >> To: [email protected]
> >> Subject: [Issue 3951] serf fail prop_tests.py 3 with 1.6 mod_dav_svn
> >>
> >> http://subversion.tigris.org/issues/show_bug.cgi?id=3951
> >>
> >>
> >>
> >>
> >>
> >>
> >> ------- Additional comments from [email protected] Thu Jul  7 03:56:05
> > -0700
> >> 2011 -------
> >> As issue #3948 the client gets both props via serf/1.6 and only the new
> > prop
> >> in
> >> other cases.  When merging the props update_editor.c:close_directory
> calls
> >> props.c:svn_wc__merge_props, which calls
> >> props.c:apply_single_prop_change which
> >> calls props.c:apply_single_generic_prop_change, and there we have:
> >>
> >> 1394      /* If working_val is the same as new_val already then there
is
> >> 1395       * nothing to do */
> >> 1396      if (working_val && new_val
> >> 1397          && svn_string_compare(working_val, new_val))
> >> 1398        {
> >> 1399           set_prop_merge_state(state, svn_wc_notify_state_merged);
> >> 1400        }
> >
> > This exact block was added by stsp in r1136063, about a month ago.
> > [[
> > Fix issue #3919. During a merge of a property, add a check against the
> > incoming new property value and the working copy value. If they
> > already match, then the merge trivially succeeds.
> >
> > * subversion/libsvn_wc/props.c
> >   (apply_single_generic_prop_change): Do nothing if the incoming new
> >   property value already matches the working value.
> >
> > Patch by: Brian Neal <[email protected]>
> >           me
> > ]]
> >
> > I think we shouldn't set the state to merged here, (but of course allow
the
> > merge without conflict).
> 
> This is a bit of a special case when base==working==incoming.  Normally
> we don't see incoming==base.  I am experimenting with this patch:

Via mod-dav we have a few cases where we receive unchanged properties.
(I think Paul Burba knows more about this than anybody would like to know)

        Bert

Reply via email to