[PATCH 4 of 4 evolve-ext] evolve: add --rev option to the evolve command

[Pierre-Yves David]

On 05/05/2015 03:52 PM, Laurent Charignon wrote:
>
>
> On 5/5/15, 3:18 PM, "Pierre-Yves David" <pierre-yves.david at ens-lyon.org>
> wrote:
>
>>
>>
>> On 05/05/2015 02:29 PM, Laurent Charignon wrote:
>>> # HG changeset patch
>>> # User Laurent Charignon <lcharignon at fb.com>
>>> # Date 1430861159 25200
>>> #      Tue May 05 14:25:59 2015 -0700
>>> # Node ID 0e29ac55b21ab929cca0d68045a98c490a6bac23
>>> # Parent  0af82f6387fce507cd856aa0866534af0be65c98
>>> evolve: add --rev option to the evolve command
>>>
>>> This patch is part of a series of patches to refactor the evolve method
>>> and
>>> make it more readable. We introduce a new --rev flag to specify a revset
>>> where to solve the troubles instead of looking from the parent
>>> changeset.
>>> All add a test checks that --rev  works with several commits
>>>
>>> diff --git a/hgext/evolve.py b/hgext/evolve.py
>>> --- a/hgext/evolve.py
>>> +++ b/hgext/evolve.py
>>> @@ -1213,12 +1213,14 @@
>>>        else:
>>>            ui.write_err(_('no troubled changesets\n'))
>>>            return 1
>>> +
>>>    @command('^evolve|stabilize|solve',
>>>        [('n', 'dry-run', False,
>>>            'do not perform actions, just print what would be done'),
>>>         ('', 'confirm', False,
>>>            'ask for confirmation before performing the action'),
>>>        ('A', 'any', False, 'also consider troubled changesets unrelated
>>> to current working directory'),
>>> +    ('r', 'rev', '', 'revset to find troubles in'),
>>
>> Not sure if using "revset" is very clear here. you usually just talk
>> about "revs". What about
>>
>>   'revisions to be evolved'
>>
>> or
>>
>>   'solves troubles of theses revisions'
>>
>>>        ('a', 'all', False, 'evolve all troubled changesets in the repo '
>>>                            '(implies any)'),
>>>        ('c', 'continue', False, 'continue an interrupted evolution'),
>>> @@ -1249,12 +1251,14 @@
>>>        The working directory is updated to the newly created revision.
>>>        """
>>>
>>> +    # Options
>>>        contopt = opts['continue']
>>>        anyopt = opts['any']
>>>        allopt = opts['all']
>>>        startnode = repo['.']
>>>        dryrunopt = opts['dry_run']
>>>        confirmopt = opts['confirm']
>>> +    revopt = opts['rev']
>>>        ui.setconfig('ui', 'forcemerge', opts.get('tool', ''), 'evolve')
>>>        troubled = set(repo.revs('troubled()'))
>>>
>>> @@ -1264,7 +1268,7 @@
>>>        showprogress = allopt
>>>
>>>        def progresscb():
>>> -        if allopt:
>>> +        if revopt or allopt:
>>>                ui.progress('evolve', seen, unit='changesets',
>>> total=count)
>>>
>>>        def cleanup(ui, repo, startnode, showprogress):
>>> @@ -1281,9 +1285,25 @@
>>>                raise util.Abort('cannot specify both "--all" and
>>> "--continue"')
>>>            graftcmd = commands.table['graft'][0]
>>>            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 = 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()
>>> +            cleanup(ui, repo, startnode, showprogress)
>>> +            return
>>
>> I'm a bit sad to see a whole new block added instead of moving to a:
>>
>> 1) list revision we need to evolve
>> 1.a) if --rev, then use this list (well, all unstable in it).
>> 1.b) if --all, then use all unstables.
>> 2.c) else just pick the next one.
>>
>> This approach would probably cause a couple of issue where evolve won't
>> evolve everything (case where stuff are evolved in the wrong order,
>> multiple troubles on a revision, etc), but is would more in the right
>> direction.
>>
>> I would be okay with evolve --all "regressing" for such corner case
>> during a couple of revision in such case is it help moving in the right
>> direction and we have the rest of the stack making things up to a
>> sensible behavior.
>> In all case you planning to unify the case soon, taking the above corner
>> case in consideration ?
>
> I am actually doing exactly what you describe in the patch series coming
> up after :).
> I just wanted to do it bit by bit as we usually do.

Deal!

-- 
Pierre-Yves David