On Tue, Mar 20, 2012 at 3:42 AM, Philip Martin <philip.mar...@wandisco.com> wrote: > Joe Swatosh <joe.swat...@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