[PATCH 4 of 5 v4] revlog: REVIDX_ISLARGEFILE flag

[Rémi Chaintron]

On Tue, 29 Nov 2016 at 06:59 Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 11/23/2016 06:39 PM, Remi Chaintron wrote:
> > # HG changeset patch
> > # User Remi Chaintron <remi at fb.com>
> > # Date 1479922644 0
> > #      Wed Nov 23 17:37:24 2016 +0000
> > # Branch stable
> > # Node ID 75ee4746c198f039a39400e855e9335afc34f1dd
> > # Parent  da91f91e979d6bf807912e956cf2f29573ede56f
> > revlog: REVIDX_ISLARGEFILE flag
> >
> > Add the REVIDX_ISLARGEFILE flag for the `lfs` extension to interact with
> > revisions by registering transforms in the flagprocessor.
>
> small naming question: Should we actually call this 'lfs'/'LARGEFILE'.
> Of courses. the extension using it is intended for large file. However,
> the core semantic of this 'flag' seems to be "the content is stored
> outsided of revlog". This external storage could be applied to any use
> cases (eg, fetching sensitive content from a secure server on update).
>
> What do you think about adapting the name to reflect this?
>

 That's a good point, and it depends on what we want to do with these
flags. My understanding was that we wanted them to represent extension
flags (at least a few of them).

One aspect to consider is that if we were to rename this flag to something
more generic (such as "REVIDX_EXTERNAL_STORAGE" for example), we might end
up in a situation where this is used by different extensions with different
behaviors, that might then become incompatible.
One solution moving forward might be to allow extensions to register
several transforms on a single flag, but this will make handling
non-commutative operations more doable. This might be something worth
iterating over, though.

One aspect Augie and I discussed was to keep a few placeholder flags for
home brewed extensions to register transforms on.

-- 
Rémi
-- 
Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161129/1b848902/attachment.html>