[PATCH 6 of 6] revset: fix a crash with 'roots(wdir())'
Matt Harbison
mharbison72 at gmail.com
Wed Jul 1 20:28:47 CDT 2015
On Wed, 01 Jul 2015 09:01:17 -0400, Yuya Nishihara <yuya at tcha.org> wrote:
> On Tue, 30 Jun 2015 23:31:32 -0400, Matt Harbison wrote:
>> On Tue, 30 Jun 2015 23:24:32 -0400, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org> wrote:
>> > On 06/30/2015 07:56 PM, Matt Harbison wrote:
>> >> # HG changeset patch
>> >> # User Matt Harbison <matt_harbison at yahoo.com>
>> >> # Date 1435715342 14400
>> >> # Tue Jun 30 21:49:02 2015 -0400
>> >> # Node ID c3aecbbe50596e54402e4bd98931d33f1b2d5d01
>> >> # Parent e26c2caf800020627f58e45f799ce932c6aee761
>> >> revset: fix a crash with 'roots(wdir())'
>> >
>> > This series worries me about two things:
>> >
>> > 1) performance impact, can we get than benchmarked
>>
>> I've seen you do benchmarking patches before, but admittedly didn't pay
>> much attention to what you were doing or how to benchmark. Can you
>> point
>> me to some specific steps to perform?
>>
>> > 2) this is a lot of churn using None, could we settle for another
>> value
>> > (max int) and move toward that instead?
>>
>> https://www.selenic.com/pipermail/mercurial-devel/2015-June/071656.html
>
> It means all "None"s in this series will have to be replaced by wdirrev.
> Perhaps I should send my wdirrev patches soon.
I'll set this aside for now then- they aren't currently an issue for me.
I just seemed worth fixing all of the changelog related errors after
stumbling on it in heads().
> I want to add one more thing:
>
> 3) can we have a function that is as fast as cl.parentrevs(r) and can
> process
> wdir() ?
Something like this in revset.py? It looks like an optimization to not go
through context.
def _parentrevs(repo, cl, r):
if r is not None:
return cl.parentrevs(r)
else:
return [p.rev() for p in repo[r].parents()]
The only reason I didn't do it was because with the local changelog
caching optimization, I assumed calling a function over and over would be
unacceptable overhead.
More information about the Mercurial-devel
mailing list