[PATCH 1 of 2] config: introduce load order tracking

[Martin von Zweigbergk]

I'd also be happy to see the immutable configs series land. Yuya, do you
remember what about it you found over engineered? Perhaps it wouldn't be
hard to fix those things and land it.

On Tue, Jul 10, 2018, 06:55 Boris FELD <boris.feld at octobus.net> wrote:

> On 09/07/2018 14:50, Yuya Nishihara wrote:
> > On Mon, 09 Jul 2018 12:12:21 +0200, Boris Feld wrote:
> >> # HG changeset patch
> >> # User Boris Feld <boris.feld at octobus.net>
> >> # Date 1530887625 -7200
> >> #      Fri Jul 06 16:33:45 2018 +0200
> >> # Node ID 1019d8a4f6b810aaa63651ed56b29668650f590e
> >> # Parent  8c38d29482177cd40243a008057d6762c7d23c6f
> >> # EXP-Topic config-order
> >> # Available At https://bitbucket.org/octobus/mercurial-devel/
> >> #              hg pull https://bitbucket.org/octobus/mercurial-devel/
> -r 1019d8a4f6b8
> >> config: introduce load order tracking
> >>
> >> Configuration values reads from disk are now associated with the index
> of the
> >> file they came from. (First loaded file has index 0, second file index
> 1,
> >> etc…).
> >>
> >> This will ultimately allow us to use the alias value of a configuration
> item
> >> if it was defined in a higher priority file than the configuration item
> value
> >> itself.
> >>
> >> See next changeset for details.
> >>
> >> Value set directly through the code or through the command line have
> the highest
> >> priority.
> > Didn't read this thoroughly, but have you tried making configs layered
> (e.g.
> > overlay -> repo -> user -> env -> system)?
> >
> >
> https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-March/095733.html
> >
> > The previous RFC series seems a bit over engineered, but I think the idea
> > behind it is probably better overall than keep track of the "level" for
> each
> > item. We can get rid of the "cow" hack, configoverride() can be instant,
> etc.
>
> The layered approach seems to be the right architecture but will require
> more refactoring and careful works to make it right. We would like to
> favor for the current simpler, hackier, approach and prepare the road to
> the layered configuration way.
>
> The layers would have the biggest impact with chg and we plan to take a
> look at it once we have chg works in our schedule.
>
> >
> >> --- a/mercurial/config.py
> >> +++ b/mercurial/config.py
> >>       def restore(self, data):
> >>           """restore data returned by self.backup"""
> >>           self._source = self._source.preparewrite()
> >> -        if len(data) == 4:
> >> +        self._level = self._level.preparewrite()
> >> +        if len(data) == 5:
> >>               # restore old data
> >> -            section, item, value, source = data
> >> +            section, item, value, source, level = data
> >>               self._data[section] = self._data[section].preparewrite()
> >>               self._data[section][item] = value
> >>               self._source[(section, item)] = source
> >> +            self._source[(section, item)] = level
> > self._level ?
> >
> >> --- a/mercurial/ui.py
> >> +++ b/mercurial/ui.py
> >> @@ -191,6 +191,9 @@ def _catchterm(*args):
> >>   # _reqexithandlers: callbacks run at the end of a request
> >>   _reqexithandlers = []
> >>
> >> +# config level set directly have higher level than those from disk
> >> +directconfig = sys.maxint
> > sys.maxint no longer exists in Python 3.
> > _______________________________________________
> > Mercurial-devel mailing list
> > Mercurial-devel at mercurial-scm.org
> > https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20180710/1be4a9e6/attachment.html>