On Wed, Mar 21, 2012 at 8:24 AM, Philip Martin
<philip.martin_at_wandisco.com> wrote:
> Joe Swatosh <joe.swatosh_at_gmail.com> writes:
>
>> On Wed, Mar 21, 2012 at 3:33 AM, Philip Martin
>> <philip.martin_at_wandisco.com> wrote:
>>> Joe Swatosh <joe.swatosh_at_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.
As you point out later in the thread, yes the Subversion libraries changed.
And you're hitting on the main point that I am failing to communicate.
The repos.Node structure *IS* an instance of a svn_repos_node_t
struct, just wrapped up by SWIG into something accessible from Ruby.
>
>
> 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.
As I suspected.
>
>>
>> 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?
>
Yes, and thank you for finding a reproduction recipe, I fiddled with
it for a while, but I don't think I tried svnlook.
Also, thanks again for bringing up the original failure. I don't have
as much time to devote to supporting this as I used to, so this kind
of pointer is a big help to me to know how to focus the limited time I
have.
What is the best way to proceed? Revert the Hyrum's commit of my patch
that hid the change in behavior? Can you (or someone else) write a
test that makes direct assertions about this behavior, so that the
only test of it isn't hidden away in the Ruby bindings tests? Any
brainwaves on getting the behavior back (short of reverting r1293375)?
Or if you decide that the new behavior is correct, still revert my
initial patch and apply the new one?
Way more questions that answers, I'm afraid,
--
Joe
Received on 2012-03-22 06:49:25 CET