[PATCH 1 of 5 evolve-ext] evolve: don't use python sets on top of revset for evolve --rev

[Pierre-Yves David]

On 05/13/2015 05:26 PM, Laurent Charignon wrote:
>
>
> On 5/13/15, 5:12 PM, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org>
> wrote:
>
>>
>>
>> On 05/13/2015 10:04 AM, Laurent Charignon wrote:
>>> # HG changeset patch
>>> # User Laurent Charignon <lcharignon at fb.com>
>>> # Date 1431532991 25200
>>> #      Wed May 13 09:03:11 2015 -0700
>>> # Node ID 08577d19560731490ddf3446ebe785ce3219b52a
>>> # Parent  5e82d78f5872c9503d7b6691c594a13794a9b4a4
>>> evolve: don't use python sets on top of revset for evolve --rev
>>>
>>> In --rev we were wrapping the revsets in python sets.
>>> This is wrong as the use python sets force the wrapper revision set to
>>> be
>>> computed earlier than it has to and have no order guarantee.
>>> Removing this wrapping changes a test because the ordering does not
>>> appear to
>>> be the same but the end result is the same.
>>>
>>> diff --git a/hgext/evolve.py b/hgext/evolve.py
>>> --- a/hgext/evolve.py
>>> +++ b/hgext/evolve.py
>>> @@ -1303,20 +1303,16 @@
>>>            return graftcmd(ui, repo, old_obsolete=True, **{'continue':
>>> True})
>>>        # Rev specified on the commands line
>>>        if revopt:
>>> -        revs = set(repo.revs(revopt))
>>> -        troubled = set(repo.revs('troubled()'))
>>> +        revs = repo.revs(revopt)
>>> +        troubled = repo.revs('troubled()')
>>
>> This is greate
>>
>>>            _revs = revs & troubled
>>>            if not _revs:
>>>                ui.write_err("No troubled changes in the specified
>>> revset")
>>>            else:
>>> -            # For the progress bar to show
>>> -            count = len(_revs)
>>>                for rev in _revs:
>>> -                progresscb()
>>>                    _solveone(ui, repo, repo[rev], dryrunopt, confirmopt,
>>>                            progresscb)
>>>                    seen += 1
>>> -            progresscb()
>>
>> Wait, what? Why are we dropping the progress callback in the process?
>
> Because we can't now how many we have to process since the set is lazily
> computed

As far as I know:

1) smartset class have __len__ methods

2) dropping this from the patch did not lead to any crash

If there is any failure with this code dropped, we should fix (1) and 
make sure (2) yell about them.

-- 
Pierre-Yves David