You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Hyrum K Wright <hy...@hyrumwright.org> on 2011/05/18 01:11:09 UTC
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.
-Hyrum
On Tue, May 17, 2011 at 10:40 PM, <rh...@apache.org> wrote:
> Author: rhuijben
> Date: Tue May 17 22:40:07 2011
> New Revision: 1104610
>
> URL: http://svn.apache.org/viewvc?rev=1104610&view=rev
> Log:
> Temporarily revert r1104383 (and to resolve conflicts also r1104400) as
> these revisions cause some very hard to diagnose problems in the property
> handling, which breaks on all buildbots.
>
> * libsvn_wc/props.c
> * libsvn_wc/wc_db.c
> * libsvn_wc/wc_db.h
> svn merge -c -1104400,-1104383 ^/subversion/trunk
>
> Modified:
> subversion/trunk/subversion/libsvn_wc/props.c
> subversion/trunk/subversion/libsvn_wc/wc_db.c
> subversion/trunk/subversion/libsvn_wc/wc_db.h
>
> Modified: subversion/trunk/subversion/libsvn_wc/props.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/props.c?rev=1104610&r1=1104609&r2=1104610&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_wc/props.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/props.c Tue May 17 22:40:07 2011
> @@ -1665,34 +1665,6 @@ svn_wc_prop_list2(apr_hash_t **props,
> scratch_pool));
> }
>
> -struct propname_filter_baton_t {
> - svn_wc__proplist_receiver_t receiver_func;
> - void *receiver_baton;
> - const char *propname;
> -};
> -
> -static svn_error_t *
> -propname_filter_receiver(void *baton,
> - const char *local_abspath,
> - apr_hash_t *props,
> - apr_pool_t *scratch_pool)
> -{
> - struct propname_filter_baton_t *pfb = baton;
> - const svn_string_t *propval = apr_hash_get(props, pfb->propname,
> - APR_HASH_KEY_STRING);
> -
> - if (propval)
> - {
> - props = apr_hash_make(scratch_pool);
> - apr_hash_set(props, pfb->propname, APR_HASH_KEY_STRING, propval);
> -
> - SVN_ERR(pfb->receiver_func(pfb->receiver_baton, local_abspath, props,
> - scratch_pool));
> - }
> -
> - return SVN_NO_ERROR;
> -}
> -
> svn_error_t *
> svn_wc__prop_list_recursive(svn_wc_context_t *wc_ctx,
> const char *local_abspath,
> @@ -1706,23 +1678,40 @@ svn_wc__prop_list_recursive(svn_wc_conte
> void *cancel_baton,
> apr_pool_t *scratch_pool)
> {
> - svn_wc__proplist_receiver_t receiver = receiver_func;
> - void *baton = receiver_baton;
> -
> - struct propname_filter_baton_t pfb = { receiver_func, receiver_baton,
> - propname };
> -
> - if (propname)
> + switch (depth)
> {
> - baton = &pfb;
> - receiver = propname_filter_receiver;
> + case svn_depth_empty:
> + {
> + apr_hash_t *props;
> +
> + if (pristine)
> + SVN_ERR(svn_wc__db_read_pristine_props(&props, wc_ctx->db,
> + local_abspath,
> + scratch_pool, scratch_pool));
> + else
> + SVN_ERR(svn_wc__db_read_props(&props, wc_ctx->db, local_abspath,
> + scratch_pool, scratch_pool));
> +
> + if (receiver_func && props && apr_hash_count(props) > 0)
> + SVN_ERR((*receiver_func)(receiver_baton, local_abspath, props,
> + scratch_pool));
> + }
> + break;
> + case svn_depth_files:
> + case svn_depth_immediates:
> + case svn_depth_infinity:
> + SVN_ERR(svn_wc__db_read_props_streamily(wc_ctx->db, local_abspath,
> + propname, depth,
> + base_props, pristine,
> + receiver_func, receiver_baton,
> + cancel_func, cancel_baton,
> + scratch_pool));
> + break;
> + default:
> + SVN_ERR_MALFUNCTION();
> }
>
> - return svn_wc__db_read_props_streamily(wc_ctx->db, local_abspath, depth,
> - base_props, pristine,
> - receiver, baton,
> - cancel_func, cancel_baton,
> - scratch_pool);
> + return SVN_NO_ERROR;
> }
>
> svn_error_t *
>
> Modified: subversion/trunk/subversion/libsvn_wc/wc_db.c
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db.c?rev=1104610&r1=1104609&r2=1104610&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_wc/wc_db.c (original)
> +++ subversion/trunk/subversion/libsvn_wc/wc_db.c Tue May 17 22:40:07 2011
> @@ -7629,6 +7629,7 @@ cache_props_recursive(void *cb_baton,
> svn_error_t *
> svn_wc__db_read_props_streamily(svn_wc__db_t *db,
> const char *local_abspath,
> + const char *propname,
> svn_depth_t depth,
> svn_boolean_t base_props,
> svn_boolean_t pristine,
> @@ -7647,6 +7648,9 @@ svn_wc__db_read_props_streamily(svn_wc__
>
> SVN_ERR_ASSERT(svn_dirent_is_absolute(local_abspath));
> SVN_ERR_ASSERT(receiver_func);
> + SVN_ERR_ASSERT((depth == svn_depth_files) ||
> + (depth == svn_depth_immediates) ||
> + (depth == svn_depth_infinity));
>
> SVN_ERR(svn_wc__db_wcroot_parse_local_abspath(&wcroot, &local_relpath,
> db, local_abspath,
> @@ -7692,8 +7696,25 @@ svn_wc__db_read_props_streamily(svn_wc__
> child_abspath = svn_dirent_join(wcroot->abspath,
> child_relpath, iterpool);
>
> - SVN_ERR(receiver_func(receiver_baton, child_abspath, props,
> - iterpool));
> + /* Filter on the propname, if given one. */
> + if (propname)
> + {
> + svn_string_t *propval = apr_hash_get(props, propname,
> + APR_HASH_KEY_STRING);
> +
> + if (propval)
> + {
> + props = apr_hash_make(iterpool);
> + apr_hash_set(props, propname, APR_HASH_KEY_STRING,
> + propval);
> + }
> + else
> + props = NULL;
> + }
> +
> + if (props)
> + SVN_ERR(receiver_func(receiver_baton, child_abspath, props,
> + iterpool));
> }
>
> SVN_ERR(svn_sqlite__step(&have_row, stmt));
>
> Modified: subversion/trunk/subversion/libsvn_wc/wc_db.h
> URL: http://svn.apache.org/viewvc/subversion/trunk/subversion/libsvn_wc/wc_db.h?rev=1104610&r1=1104609&r2=1104610&view=diff
> ==============================================================================
> --- subversion/trunk/subversion/libsvn_wc/wc_db.h (original)
> +++ subversion/trunk/subversion/libsvn_wc/wc_db.h Tue May 17 22:40:07 2011
> @@ -2017,10 +2017,14 @@ svn_wc__db_read_props(apr_hash_t **props
> *
> * If BASE_PROPS is FALSE and, PRISTINE is TRUE, the local modifications will
> * be suppressed. If PRISTINE is FALSE, local modifications will be visible.
> + *
> + * NOTE: The only valid values for DEPTH are svn_depth_files,
> + * svn_depth_immediates, and svn_depth_infinity.
> */
> svn_error_t *
> svn_wc__db_read_props_streamily(svn_wc__db_t *db,
> const char *local_abspath,
> + const char *propname,
> svn_depth_t depth,
> svn_boolean_t base_props,
> svn_boolean_t pristine,
>
>
>
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, May 18, 2011 at 11:13 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> Sent: woensdag 18 mei 2011 11:11
>> To: Bert Huijben
>> Cc: dev@subversion.apache.org; commits@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 <be...@qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> >> Sent: woensdag 18 mei 2011 1:11
>> >> To: dev@subversion.apache.org
>> >> Cc: commits@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
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, May 18, 2011 at 11:13 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> Sent: woensdag 18 mei 2011 11:11
>> To: Bert Huijben
>> Cc: dev@subversion.apache.org; commits@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 <be...@qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> >> Sent: woensdag 18 mei 2011 1:11
>> >> To: dev@subversion.apache.org
>> >> Cc: commits@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
RE: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> Sent: woensdag 18 mei 2011 11:11
> To: Bert Huijben
> Cc: dev@subversion.apache.org; commits@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 <be...@qqmail.nl> wrote:
> >> -----Original Message-----
> >> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> >> Sent: woensdag 18 mei 2011 1:11
> >> To: dev@subversion.apache.org
> >> Cc: commits@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
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)
Bert
RE: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> Sent: woensdag 18 mei 2011 11:11
> To: Bert Huijben
> Cc: dev@subversion.apache.org; commits@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 <be...@qqmail.nl> wrote:
> >> -----Original Message-----
> >> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> >> Sent: woensdag 18 mei 2011 1:11
> >> To: dev@subversion.apache.org
> >> Cc: commits@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
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)
Bert
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, May 18, 2011 at 1:48 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> Sent: woensdag 18 mei 2011 1:11
>> To: dev@subversion.apache.org
>> Cc: commits@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...
-Hyrum
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, May 18, 2011 at 1:48 AM, Bert Huijben <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> Sent: woensdag 18 mei 2011 1:11
>> To: dev@subversion.apache.org
>> Cc: commits@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...
-Hyrum
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Wed, May 18, 2011 at 11:20 AM, Bert Huijben <be...@qqmail.nl> wrote:
>
>
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: woensdag 18 mei 2011 11:16
>> To: Bert Huijben
>> Cc: dev@subversion.apache.org; Hyrum K Wright
>> 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 05:11, Bert Huijben <be...@qqmail.nl> wrote:
>> >> -----Original Message-----
>> >> From: Greg Stein [mailto:gstein@gmail.com]
>> >> Sent: woensdag 18 mei 2011 11:07
>> >> To: dev@subversion.apache.org
>> >> Cc: Hyrum K Wright
>> >> Subject: RE: svn commit: r1104610 - in
>> >> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
>> >>
>> >> No, we said if somebody breaks the build, then it can be reverted.
>> >>
>> >> Breaking the tests does not qualify. You were out of line. I just got
>> >> telling off people in Lucene-land for this. I also said that if it were
> up
>> >> to me, I would warn somebody about the anti social behavior once, and
>> >> remove
>> >> their commit privs on the second time. It is THAT much of a problem in
> the
>> >> community dynamics.
>> >>
>> >> Don't do that again.
>> >
>> > Does breaking all the property handling code qualify?
>>
>> No.
>>
>> If you felt the changes were interfering with your work, then you can
>> always apply a reversion to your local working copy to continue your
>> work. Then, when Hyrum got back online, he could figure out what he
>> did and how to move it forward.
>>
>> For most people, his changes may have had no impact at all.
>
> Well, yesterday afternoon I had 4 individuals asking me in person why their
> test were broken, and this was why.
> (There was no problem in neon after all).
Did a similar discussion happen on the mailing list? If I doesn't
happen on the list, it's just hearsay. (Incidentally, that's why
we're having this discussion on the mailing, rather than in person,
even though we're in the same room.)
I'll readily claim the fault with breaking the tests. All I'm asking
is that in the future such problems are discussed, rather than
reverted out-of-hand. I appreciate you fixing them, but I'd hoped to
learn something from the experience, rather than just having the
problem fixed for me.
> If I would have committed a change with similar breakage you would have
> shouted at me.
> And because Hyrum is our release manager, or maybe because he pays you some
> checks, you threat him differently?
For the record, I don't pay any checks to Greg (and he has shouted at
me a number of times).
-Hyrum
Re: svn commit: r1104610 - in
/subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Stefan Sperling <st...@elego.de>.
On Wed, May 18, 2011 at 11:27:27AM +0200, C. Michael Pilato wrote:
> Overall, I think the tone of this discussion is deplorable. There's no need
> to be rattling off threats of dropped commit privileges, etc.
+1
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by "C. Michael Pilato" <cm...@collab.net>.
On 05/18/2011 11:20 AM, Bert Huijben wrote:
> If I would have committed a change with similar breakage you would have
> shouted at me.
> And because Hyrum is our release manager, or maybe because he pays you some
> checks, you threat him differently?
Bert, this is foul play, and I don't mind saying so. The concern voiced
here is that Greg didn't have the chance to even shout at Hyrum because you
took a community-discouraged unilateral action in response to the problem.
Overall, I think the tone of this discussion is deplorable. There's no need
to be rattling off threats of dropped commit privileges, etc. Do I need to
lock you boys in a small room here in a Berlin so you can work this out? :-)
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn commit: r1104610 - in
/subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Greg Stein wrote on Wed, May 18, 2011 at 05:27:19 -0400:
> On Wed, May 18, 2011 at 05:20, Bert Huijben <be...@qqmail.nl> wrote:
> >...
> > And because Hyrum is our release manager, or maybe because he pays you some
> > checks, you threat him differently?
>
> Now you're totally out of line.
>
You're all in the same room, why don't you stop talking through emails?
> -g
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Greg Stein <gs...@gmail.com>.
On Wed, May 18, 2011 at 05:20, Bert Huijben <be...@qqmail.nl> wrote:
>...
> And because Hyrum is our release manager, or maybe because he pays you some
> checks, you threat him differently?
Now you're totally out of line.
-g
RE: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: woensdag 18 mei 2011 11:16
> To: Bert Huijben
> Cc: dev@subversion.apache.org; Hyrum K Wright
> 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 05:11, Bert Huijben <be...@qqmail.nl> wrote:
> >> -----Original Message-----
> >> From: Greg Stein [mailto:gstein@gmail.com]
> >> Sent: woensdag 18 mei 2011 11:07
> >> To: dev@subversion.apache.org
> >> Cc: Hyrum K Wright
> >> Subject: RE: svn commit: r1104610 - in
> >> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
> >>
> >> No, we said if somebody breaks the build, then it can be reverted.
> >>
> >> Breaking the tests does not qualify. You were out of line. I just got
> >> telling off people in Lucene-land for this. I also said that if it were
up
> >> to me, I would warn somebody about the anti social behavior once, and
> >> remove
> >> their commit privs on the second time. It is THAT much of a problem in
the
> >> community dynamics.
> >>
> >> Don't do that again.
> >
> > Does breaking all the property handling code qualify?
>
> No.
>
> If you felt the changes were interfering with your work, then you can
> always apply a reversion to your local working copy to continue your
> work. Then, when Hyrum got back online, he could figure out what he
> did and how to move it forward.
>
> For most people, his changes may have had no impact at all.
Well, yesterday afternoon I had 4 individuals asking me in person why their
test were broken, and this was why.
(There was no problem in neon after all).
If I would have committed a change with similar breakage you would have
shouted at me.
And because Hyrum is our release manager, or maybe because he pays you some
checks, you threat him differently?
Bert
Re: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Greg Stein <gs...@gmail.com>.
On Wed, May 18, 2011 at 05:11, Bert Huijben <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Greg Stein [mailto:gstein@gmail.com]
>> Sent: woensdag 18 mei 2011 11:07
>> To: dev@subversion.apache.org
>> Cc: Hyrum K Wright
>> Subject: RE: svn commit: r1104610 - in
>> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
>>
>> No, we said if somebody breaks the build, then it can be reverted.
>>
>> Breaking the tests does not qualify. You were out of line. I just got
>> telling off people in Lucene-land for this. I also said that if it were up
>> to me, I would warn somebody about the anti social behavior once, and
>> remove
>> their commit privs on the second time. It is THAT much of a problem in the
>> community dynamics.
>>
>> Don't do that again.
>
> Does breaking all the property handling code qualify?
No.
If you felt the changes were interfering with your work, then you can
always apply a reversion to your local working copy to continue your
work. Then, when Hyrum got back online, he could figure out what he
did and how to move it forward.
For most people, his changes may have had no impact at all.
> That was what happened...
>
> Not just a few random tests. There were dozens of tests broken, but the test
> suite itself was broken in a different way that didn't catch it.
>
> All the single property accesses were routed through the new depthy code,
> that was fundamentally flawed until I fixed it. (Which was impossible to
> find without reverting).
Yup. And you could have done that entirely locally. You could have
*worked with* Hyrum to get through this.
In short, your behavior was disrespectful and anti-social.
-g
RE: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: woensdag 18 mei 2011 11:07
> To: dev@subversion.apache.org
> Cc: Hyrum K Wright
> Subject: RE: svn commit: r1104610 - in
> /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
>
> No, we said if somebody breaks the build, then it can be reverted.
>
> Breaking the tests does not qualify. You were out of line. I just got
> telling off people in Lucene-land for this. I also said that if it were up
> to me, I would warn somebody about the anti social behavior once, and
> remove
> their commit privs on the second time. It is THAT much of a problem in the
> community dynamics.
>
> Don't do that again.
Does breaking all the property handling code qualify?
That was what happened...
Not just a few random tests. There were dozens of tests broken, but the test
suite itself was broken in a different way that didn't catch it.
All the single property accesses were routed through the new depthy code,
that was fundamentally flawed until I fixed it. (Which was impossible to
find without reverting).
Bert
RE: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc:
props.c wc_db.c wc_db.h
Posted by Greg Stein <gs...@gmail.com>.
No, we said if somebody breaks the build, then it can be reverted.
Breaking the tests does not qualify. You were out of line. I just got
telling off people in Lucene-land for this. I also said that if it were up
to me, I would warn somebody about the anti social behavior once, and remove
their commit privs on the second time. It is THAT much of a problem in the
community dynamics.
Don't do that again.
-g
On May 18, 2011 1:50 AM, "Bert Huijben" <be...@qqmail.nl> wrote:
>> -----Original Message-----
>> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
>> Sent: woensdag 18 mei 2011 1:11
>> To: dev@subversion.apache.org
>> Cc: commits@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)
> 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... :-)
> 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.
>
> Bert
>
RE: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> Sent: woensdag 18 mei 2011 1:11
> To: dev@subversion.apache.org
> Cc: commits@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)
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... :-)
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.
Bert
RE: svn commit: r1104610 - in /subversion/trunk/subversion/libsvn_wc: props.c wc_db.c wc_db.h
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Hyrum K Wright [mailto:hyrum@hyrumwright.org]
> Sent: woensdag 18 mei 2011 1:11
> To: dev@subversion.apache.org
> Cc: commits@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)
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... :-)
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.
Bert