[PATCH 3 of 3] revset: drop factory that promotes spanset to fullreposet

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed May 6 02:11:50 CDT 2015



On 05/04/2015 06:05 PM, Yuya Nishihara wrote:
> On Mon, 04 May 2015 17:19:35 -0700, Pierre-Yves David wrote:
>> On 02/10/2015 07:50 AM, Yuya Nishihara wrote:
>>> # HG changeset patch
>>> # User Yuya Nishihara <yuya at tcha.org>
>>> # Date 1420728195 -32400
>>> #      Thu Jan 08 23:43:15 2015 +0900
>>> # Node ID 9962a866325681d8e4523ea30edd3e2ed8343f98
>>> # Parent  f04a70f7f3a11b5c66dc739cdf6bcf57d59183ff
>>> revset: drop factory that promotes spanset to fullreposet
>>
>> This overlooked the 'all()' revset as a place were spanset was used
>> (making combinaison with involving all() less efficients as they
>> should). We cannot just fix 'all()' to used 'fullreposet' because
>> fullreposet is now doing working copy magic too. This lead to these two
>> test failure when tried. Yuya, can I get you to look at this?
>>
>> --- /home/marmoute/mercurial-testing/tests/test-glog.t
>> +++ /home/marmoute/mercurial-testing/tests/test-glog.t.err
>> @@ -2370,9 +2370,9 @@
>>      $ hg log -G -r 'all()' | tail -6
>>      |
>>      o  changeset:   0:f8035bb17114
>> -     user:        test
>> -     date:        Thu Jan 01 00:00:00 1970 +0000
>> -     summary:     add a
>> -
>> +  |  user:        test
>> +  |  date:        Thu Jan 01 00:00:00 1970 +0000
>> +  |  summary:     add a
>> +  |
>
> Does this solve the efficiency problem?
>
> It backs out 2de9ee016425 and wraps fullreposet at match() instead. It
> assumes that the optimization provided by fullreposet is necessary while
> calculating revset.

It seems to fix it. but it regress stuff related to "null" handling (And 
probably working directory handling) (eg "null and all()" would now 
return nullid).

This bring my attention on the "new" behavior of fullreposet. 
fullreposet was initially designed as an efficient replacement for 
`spanset(repo)` and it is used as such in multiple place in the code. 
However your change in d2de20e1451f turn it into a yes-card to allow 
"null" through (and also workingdirectory now?). I'm not sure we want 
that relaxed approach everywhere. Especially because:

1) It makes fullreposet ≠ spanset breaking the initial assumption
2) It makes fullreposet non returnable to user code.

Could we put back fullreposet to the old behavior and have an extra 
subclass especially dedicated to be the initial set? One would accept 
null and working directory when it makes sense.

On related topic, one what behavior did we settle regarding usage of 
"null" in revset? I cannot find anything related to this discussion in 
mercurial/revset.py

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list