On Mon, Apr 25, 2011 at 5:59 PM, Greg Stein <gstein_at_gmail.com> wrote:
> On Mon, Apr 25, 2011 at 18:51, Greg Stein <gstein_at_gmail.com> wrote:
>> On Mon, Apr 25, 2011 at 18:01, Hyrum Wright <hwright_at_apache.org> wrote:
>>> FYI: This has a slight alteration in the post-commit work queue item
>>> skel. If you've got un-cleaned up working copies laying around, this
>>> may negatively impact them. :)
>>>
>>> (I went ahead with the commit, without a format bump, since work queue
>>> items are short lived, and we don't make any promises of upgrading
>>> them anyway.)
>>
>> That is NOT the policy that we've chosen in the past.
>>
>> Instead, we've extended a skel so that the code can determine which
>> version you're using (eg. a new, optional element at the end). Or
>> we've chosen two different OP names ("foo" and "foo-2") that dispatch
>> to different skel parsers and call a common function.
Thanks for the background. Unfortunately, I don't know that this
policy is documented anywhere (certainly not in workqueue.h).
>> I disagree with changing the policy at this time, and would suggest
>> finding a solution that will not break working copies that have stale
>> work items in them.
>
> For this particular change, the "old" skel had three items in it (path
> and two flags). The "new" skel only has the path; any additional
> elements in the skel will be ignored.
>
> A new skel, processed by old code, would choke horribly... but the new
> code can (seemingly) interpret old skels just fine.
I've re-added placeholder values in r1096641, so that the parse doesn't choke.
-Hyrum
Received on 2011-04-26 02:56:56 CEST