[PATCH 2 of 6] transaction: use unfiltered changelog length for transaction start

Martin von Zweigbergk martinvonz at google.com
Wed May 24 19:40:13 EDT 2017


On Wed, May 24, 2017 at 4:38 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 05/24/2017 11:17 PM, Martin von Zweigbergk wrote:
>>
>> On Fri, May 19, 2017 at 1:05 PM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>>>
>>>
>>>
>>> On 05/18/2017 08:23 PM, Durham Goode wrote:
>>>>
>>>>
>>>> # HG changeset patch
>>>> # User Durham Goode <durham at fb.com>
>>>> # Date 1495129620 25200
>>>> #      Thu May 18 10:47:00 2017 -0700
>>>> # Node ID 35235b1cefb101dad0672a4c4ee9486fba8b935b
>>>> # Parent  19be454ee16925d01da8f9d329cb48556083da1b
>>>> transaction: use unfiltered changelog length for transaction start
>>>>
>>>> Previously we used the normal changelog length for the transaction
>>>> start.
>>>> This
>>>> triggered the computehidden logic which in a future patch triggers logic
>>>> in the
>>>> new hidden store which may start a transaction. This is circular and
>>>> results in
>>>> broken transaction mechanics, so let's use the unfiltered repo instead
>>>> to
>>>> avoid
>>>> triggering computehidden during transaction start.
>>>>
>>>> This seems like how it should've been in the first place anyway since
>>>> recording
>>>> the length of the filtered changelog seems odd for a transaction.
>>>>
>>>> This was causing test failures in a future patch, so test coverage will
>>>> come
>>>> from the future patch.
>>>
>>>
>>>
>>> yes, writing filtered journal seems a bit odd. However I would rather see
>>> the whole _writejournal run unfiltered.
>>>
>>> There are a '@unfilteredmethod' decorator for this purpose.
>>
>>
>> That seems like a trivial little improvement for V2. There are no
>> other calls in the method that seem like they would be affected, so it
>> should be functionally equivalent as far as I can tell.
>
>
> Yep, seems fine as a follow up.

I have assumed there will be a v2 of this series anyway, so might as
well do it right there (because it sounds like the decorator is
preferred).

>
> Cheers,
>
> --
> Pierre-Yves David


More information about the Mercurial-devel mailing list