[PATCH 09 of 13 sparse] merge: move sparse config parsing from sparse extension

[Gregory Szorc]

On Sun, Jul 2, 2017 at 8:44 AM, Martin von Zweigbergk <martinvonz at google.com
> wrote:

>
>
> On Jul 1, 2017 6:55 PM, "Gregory Szorc" <gregory.szorc at gmail.com> wrote:
>
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc at gmail.com>
> # Date 1498945185 25200
> #      Sat Jul 01 14:39:45 2017 -0700
> # Node ID a2d07300bdc999403954e965debf53db898ccdc3
> # Parent  6636a2dfa31cb84684373bf3a9fdb03c26e42f99
> merge: move sparse config parsing from sparse extension
>
> This function is generic and doesn't need to be a repo method.
>
> This patch also marks the beginning of moving code from sparse.py
> into core. The goal is for the extension to enable the feature and
> provide any UI adjustments.
>
> merge.py may seem like a weird destination. But that's
> where code for working directory updating lives. Unless we want
> to create a new module for just the sparse bits or something for
> working directory code, merge.py is the best current place.
>
>
> It seems to me like there will be too much sparse-related code for it to
> all move into merge.py. I think I'd prefer to move it into a
> mercurial/sparse.py or something like that.
>

I agree. merge.py seemed like the best place when I started this work. But
after writing a few dozen patches, there is a compelling case for a
standalone module. Especially for utility functions like parsing profiles.
Keep in mind aspects of sparse and merge are tightly coupled. I don't think
it will be easy to avoid module import cycles. So expect some
function-level imports when code is moved to a standalone module.

I'll refactor and send a new series once the first few patches are queued.
(I want to be sure people are OK with everything first.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20170702/6edac604/attachment.html>