On Wed, May 18, 2011 at 11:13 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum_at_hyrumwright.org]
>> Sent: woensdag 18 mei 2011 11:11
>> To: Bert Huijben
>> Cc: dev_at_subversion.apache.org; commits_at_subversion.apache.org
>> Subject: Re: svn commit: r1104610 - in
>> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
>>
>> On Wed, May 18, 2011 at 1:48 AM, Bert Huijben <bert_at_qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: Hyrum K Wright [mailto:hyrum_at_hyrumwright.org]
>> >> Sent: woensdag 18 mei 2011 1:11
>> >> To: dev_at_subversion.apache.org
>> >> Cc: commits_at_subversion.apache.org
>> >> Subject: Re: svn commit: r1104610 - in
>> >> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
>> >>
>> >> I understand the desire to get the buildbots green again, and I'm
>> >> sorry these revisions which I committed broke the bots, but a little
>> >> patience might have been useful here. We have a long tradition of
>> >> allowing folks to attempt to fix problems, rather than reverting their
>> >> commits without consultation. I kinda wish you'd have given me
>> >> another 12 hours to attempt to fix it, rather than reverting.
>> >
>> > We also have the generic rule that any committer (full or partial) may
>> > revert something that makes it impossible for them to do further
>> > development. (See hacking)
>>
>> No, we have a policy that people can revert changes to the *build
>> system* which prevent productivity:
>> "To prevent loss of productivity, any committer (full or partial) can
>> immediately revert any build system change that breaks their ability
>> to effectively do development on their platform of choice, as a matter
>> of ordinary routing, without fear of accusations of an over-reaction."
>> (From: http://subversion.apache.org/docs/community-
>> guide/building.html#configury
>> )
>>
>> I'm not trying to play process obstructionist, just noting that a mail
>> mentioning the breakage and indicating your intent to revert would
>> have been a nice consideration.
>>
>> > And tomorrow morning the asf repository will be readonly for quite some
>> > time, so waiting till after that will probably cause more delays.
>> >
>> > Besides, you just mailed that you weren't going to fix this issue... :-)
>>
>> I guess I should have been more clear: I'm happy to fix my own
>> breakage to the buildbots. When indicating I was moving on to other
>> things, I didn't know I'd broken the test world.
>>
>> > Somehow the test that should have picked up the original failure is
> broken.
>> > It thinks that no output at all for a recursive proplist is ok.
>> >
>> > So two different bugs (the local changes one; and the base-deleted one)
>> > together kept the prop_tests.py 15 test succeeding.
>>
>> Has this bug in the test suite been fixed? If not, I suppose that's a
>> place to start...
>
> r1104641 fixes the test suite
Great. Thanks for doing this.
> And r1104631, probably fixes most of the other problems of the patch.
> (Except for the performance regression of single node property reads, such
> as used by the merge code)
Alrighty, I'll reapply it and see what happens. Is the performance
regression theoretical or practical?
-Hyrum
Received on 2011-05-18 11:20:30 CEST