[PATCH 3 of 3] revlog: give EXTSTORED flag value to narrowhg

[Pierre-Yves David]

On 01/17/2017 09:34 PM, Augie Fackler wrote:
> On Tue, Jan 17, 2017 at 12:10:31PM -0800, Martin von Zweigbergk via Mercurial-devel wrote:
>> # HG changeset patch
>> # User Martin von Zweigbergk <martinvonz at google.com>
>> # Date 1484681102 28800
>> #      Tue Jan 17 11:25:02 2017 -0800
>> # Node ID 2fbfddbea687ad8627b26dc856694f70078eb2b4
>> # Parent  7e933c9a4009d942b88bfbcb4e579a4b3f4dceca
>> revlog: give EXTSTORED flag value to narrowhg
>
> I'm (obviously?) in favor of this patch series, especially this last
> one, but I won't pretend to be an impartial reviewer.

I went through the IRC log of the conversation between Martin von 
Zweigbergk and Durham Goode and checked the Rémi Chaintron email reply.
It seems like LFS user are fine with this early change so I'm pushing it.

> It occurred to me while talking this over with Martin that ellipsis
> nodes might actually be able to overload the ISCENSORED flag - censor
> wants to look for special metadata, but perhaps narrow's "just trust
> me on the hash of this revision" behavior is similar enough to censor
> that we should try and consolidate down to a single flag for that
> purpose. Thoughts?
>
> I'm happy to talk at length about narrowhg implementation details if
> it'll help think this through.
>
> (Note that censor doesn't even pretend to work on anything other than
> filelogs, so you'd never (today) see censor outside a
> filelog. Ellipsis nodes, on the other hand, can exist in any revlog as
> currently implemented in narrowhg.)

Given that "censor" and "ellipsis" are distinct use case, I think it 
make sense to use different flag. We have a limited amount of them, but 
we still have some room.

In addition, LFS don't really care about which flag they get as long as 
they get one and it stay stable over version. So we still have the whole 
freeze to decide on a potential drop of the REVIDX_ELLIPSIS flag.

-- 
Pierre-Yves David