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 <martinv...@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
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
