[PATCH 2 of 3 RFC] revert: add support for reverting subrepos without --no-backup and/or --all

Martin Geisler mg at aragost.com
Mon Mar 26 03:29:11 CDT 2012


Angel Ezquerra Moreu <angel.ezquerra at gmail.com> writes:

> On Mon, Mar 26, 2012 at 9:23 AM, Martin Geisler <mg at aragost.com> wrote:
>> Angel Ezquerra <angel.ezquerra at gmail.com> writes:
>>
>>> +                # 1. if the no_backup is not set, revert all modified files inside the subrepo
>>> +                # 2. update the subrepo to the revision specified in the corresponding substate dictionary
>>> +
>>> +                # the revert function name is shadowed
>>
>> The lines are very long here and check-code will complain.
>
> I did not know about check code. Actually I had heard of it on this
> list, but I had not used it before. Thanks for the pointer.

Please read

  http://mercurial.selenic.com/wiki/ContributingChanges
  http://mercurial.selenic.com/wiki/CodingStyle

if you haven't ready read them.

>>> +                        if revert_opts['all']:
>>> +                            revert(ui, ctx.sub(sname)._repo, **revert_opts)
>>> +                        else:
>>> +                            revert(ui, ctx.sub(sname)._repo, 'set:modified()', **revert_opts)
>>
>> The _repo field is private and I don't think this will work for
>> non-hg subrepos?
>>
>> When I implemented the --subrepos flags originally, I made sure to
>> let the right subclass of abstractsubrepo in subrepo.py manage the
>> recursion. That way the hgsubrepo class can trigger further recursive
>> calls by calling back to the existing implementation (see
>> hgsubrepo.status) and the gitsubrepo class can implement the logic it
>> needs and stop the recursion.
>
> Are you suggesting that I should add a "revert" method to the subrepo
> classes, which would, if implemented, call commands.revert?

Yes, more or less. I think the core revert code should go from
commands.py to cmdutil.py first so that hgsubrepo can easily reuse the
logic it needs.

-- 
Martin Geisler

aragost Trifork
Professional Mercurial support
http://www.aragost.com/mercurial/


More information about the Mercurial-devel mailing list