Re: Ruby bindings failing on buildbots

On Tue, Mar 20, 2012 at 3:42 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Joe Swatosh <joe.swatosh_at_gmail.com> writes:
>
>> I guess that deleting a property isn't considered a prop_mod on the
>> node anymore?
>
> The property delete is still reported as a property change by the
> Subversion core and still gets as far as ChangedEditor.change_file_prop
> in the Ruby bindings, see my first email in this thread.
>
> --
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com

Thanks for pointing me back to your original email. Now I've reread it
and now it makes sense, I just didn't get it before.... Sorry, all a
failure of the receiver.

I believe you are correct: it has nothing to do with the ChangedEditor.

This is what I think is happening. The implementation of
Svn::Info#get_diff (the caller of Svn::Info#get_diff_recurse) does the
following:

  tree = @repos.delta_tree(@root, @prev_rev)
  # basically:
  # svn_fs_revision_root
  # svn_repos_node_editor
  # replay...
  # set tree to svn_repos_node_from_baton (this is a svn_repos_node_t
wrapped up by swig)

  Svn::Info#get_diff then initializes the @diffs hash and calls
Svn::Info#get_diff_recurse

  Svn::Info#get_diff_recurse collects changes in this node in the
@diffs hash then uses the "child" and "sibling: members of
svn_repos_node_t to call itself to perform a recursive visit to each
node..

Before r1293375, the node that represented 'diff1.txt' in this walk
had the "prop_mod" member set true. After r1293375, the "prop_mod"
member for this node is false. Since the implementation of
Svn::Info#get_diff_recurse checks "prop_mod" member before attempting
to collect the property changes on the node, the test started failing.

My second patch removes the (optimization?) check for the "prop_mod"
member and thus always get the properties from the prior revision and
compares them with the current version. Making the test pass again for
me.

All that was the reason for the (now snarky sounding to me) comment
about deleting a property not being a prop_mod anymore. I apologize
for any snarkiness, it really wasn't intended as anything more than a
comment that I hoped would generate a confirming reply or a "whoops".
It would have been better to just ask the question, so I'll ask now:

Is the prop_mod not being set in this scenario for this node the
desired behavior?

--
Joe