[PATCH 2 of 5 flagprocessor v6] revlog: add 'raw' argument to revision and _addrevision

Rémi Chaintron remi.chaintron at gmail.com
Fri Dec 30 10:44:21 EST 2016


Long story short, we need to pass the raw argument to processflags() so
that it can determine which transform use. This allows to differentiate the
regular use case (transform operations such as reading from a remote store
in lfs's case) from changegroup generation and debug commands. The only way
to not pass the raw argument to revision would be to refactor all flag
processing / checkhash out of revision and _addrevision, but that seems
like a significant rework in a really core part of revlog.
On Fri, 30 Dec 2016 at 10:38, Augie Fackler <raf at durin42.com> wrote:

>
> > On Dec 30, 2016, at 5:25 AM, Pierre-Yves David <
> pierre-yves.david at ens-lyon.org> wrote:
> >
> >> This patch adds a new 'rawrevision()' method setting the 'raw' argument
> to True
> >> in the revlog.revision() call that is used to differentiate changegroup
> >> generation and debugdata related calls to revision() from regular read
> accesses.
> >
> > I don't get that part. it seems like 'rawrevision(…)' is just
> 'revision(…, raw=True)' so I do not understant why we need a new method.
> Can't we just call 'revision(…, raw=True)' directly. Am I missing
> something? Otherwise, we should just drop that method.
>
> I believe it’s so that we can have extensions hook into either reading of
> raw revisions or non-raw revisions. In a perfect world, revision() wouldn’t
> even take a raw= keyword, but I’ve lost too much context this week to help
> without rereading the whole patch (which I don’t have time for right now.)
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-- 
Rémi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20161230/378141a2/attachment.html>


More information about the Mercurial-devel mailing list