[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:46:21 EST 2016

The actual rawrevision() method is simply a personal preference as I like
to have simpler apis on operations with optional arguments and I've seen
this in other places, but I do not feel strongly about moving it to use the
raw argument in calls to revision directly. Let me know what you prefer.
On Fri, 30 Dec 2016 at 10:44, Rémi Chaintron <remi.chaintron at gmail.com>

> 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/48deb696/attachment.html>

More information about the Mercurial-devel mailing list