Joe Swatosh <joe.swat...@gmail.com> writes:

> On Wed, Mar 21, 2012 at 3:33 AM, Philip Martin
> <philip.mar...@wandisco.com> wrote:
>> Joe Swatosh <joe.swat...@gmail.com> writes:
>>
>> I don't understand why prop_mod is no longer being set.
>
> Because replay is no longer setting it?

Does that mean the core Subversion libraries have changed?  I don't do
Ruby but it prop_mod is part of the Ruby repos.Node structure, it's the
Ruby structure that is different.

>>> 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.
>>
>> That also looks dubious to me.
>>
>>> Is the prop_mod not being set in this scenario for this node the
>>> desired behavior?
>>
>> In the past a property delete caused prop_mod to be set and now it does
>> not.  The Subversion core is still reporting the property delete to the
>
> So, from the first sentence here, it sounds like the change to not
> report property deletions as "prop_mod" on the svn_repos_node_t  is
> deliberate.

I'm not aware of a deliberate change to core Subversion behaviour.
Property deletes should still be reported as property mods by the
Subversion libraries.

>> Ruby bindings layer at ChangedEditor.change_file_prop.  I don't
>
> The Ruby bindings aren't using the ChangedEditor to track these
> changes. Currently, the bindings rely on the state of the
> svn_repos_node_t structs being passed out of the replay on the node
> from the baton passed to the editor. (I think I said that right). The
> state of the graph of nodes rooted in the one from the baton changed
> after r1293375.
>
>> understand the Ruby code so I don't know why prop_mod is no longer set
>> but it seems like a bug to me.
>>
>
> Because replay is no longer setting it?
> The bindings never *set* prop_mod on the svn_repos_node_t struct, they *use* 
> it.

So, again, you think the core Subversion libraries have changed
behaviour?

-- 
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com

Reply via email to