[PATCH 01 of 11] upgrade: extract code in its own module
gregory.szorc at gmail.com
Mon Apr 10 14:47:02 EDT 2017
On Mon, Apr 10, 2017 at 11:00 AM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:
> On 04/10/2017 07:39 PM, Gregory Szorc wrote:
>> On Mon, Apr 10, 2017 at 9:48 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
>> # HG changeset patch
>> # User Pierre-Yves David <pierre-yves.david at ens-lyon.org
>> <mailto:pierre-yves.david at ens-lyon.org>>
>> # Date 1491583997 -7200
>> # Fri Apr 07 18:53:17 2017 +0200
>> # Node ID 421260c23fe9fb0afaa77bbb8c4d9d32e631d114
>> # Parent e0dc40530c5aa514feb6a09cf79ab6a3aa2ec331
>> # EXP-Topic upgraderepo
>> # Available At
>> # hg pull
>> <https://www.mercurial-scm.org/repo/users/marmoute/mercurial/> -r
>> upgrade: extract code in its own module
>> Given about 2/3 or 'mercurial.repair' is now about repository
>> upgrade, I think
>> it is fair to move it into its own module.
>> An expected benefit is the ability to drop the 'upgrade' prefix of
>> functions. This will be done in coming changesets.
>> Is there an objective to this series other than code cleanup?
> Yep, ultimately, my goal is to refactor this code in order to have access
> to all "format" item outside of a pure upgrade goal (close to current
> general idea is to be able to do something like things:
> getformatfoo(repo) -> list of "format" object with "name" and "value"
> The target usage is to provide this data to configexpress (so that client
> can tell server what format they use and server can also recommend format
> upgrade to their client).
> Do you need more details?
This sounds fine. No, I don't need any more details.
(I just didn't want to proceed with a refactor until I knew what the end
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Mercurial-devel