[PATCH 3 of 3 V4] largefiles: setup "largefiles" feature in each repositories individually

[FUJIWARA Katsunori]

At Tue, 24 Sep 2013 15:33:47 -0700,
Siddharth Agarwal wrote:
> 
> On 09/24/2013 02:05 PM, Siddharth Agarwal wrote:
> > On 09/21/2013 05:39 AM, FUJIWARA Katsunori wrote:
> >> +def featuresetup(ui, supported):
> >> +    for name, module in extensions.extensions(ui):
> >> +        if __name__ == module.__name__:
> >> +            # don't die on seeing a repo with the largefiles 
> >> requirement
> >> +            supported |= set(['largefiles'])
> >> +            return
> >
> > Is there a more elegant way to do this? Seems like basically every 
> > extension that adds something to the supported list will need to do 
> > precisely this.

What about below ?

  (1) register feature setup function to "featuresetupfuncs" of
      "localrepository" automatically, when extension module has
      "supportedfeatures" like attribute

        - are there already existing extensions with
          "supportedfeatures" like attribute for other purposes ?

and/or:

  (1) adding function like below to "extension.py", to use from
      "uisetup()" of each extensions adding features ?

      @extensions.py:
      ================================
      def featuresetupfunc(extmod, features):
          def setupfunc(ui, supported):
              for name, module in extensions(ui):
                  if extmod.__name__ == module.__name__:
                      supported |= set(features)
                      return
          return setupfunc
      ================================

      @ each extensions
      ================================
      def uisetup(ui):
          func = extensions.featuresetupfunc(uisetup.__module__)
          localrepo.localrepository.featuresetupfuncs.add(func)
      ================================


In addition to above, "localrepo.localrepository.featuresetupfuncs"
may have to be moved into "extensions" module to simplify import
dependency.


> Also, it seems like if the extension relies on the requires file to 
> figure out when to disable itself, this shouldn't be necessary at all. 
> For example, we have an out-of-tree extension called lz4revlog that 
> switches to a different compression algorithm for the revlog. The 
> extension looks at whether its corresponding entry is present in the 
> requires file, and if it is, doesn't use the alternate compression 
> algorithm to compress itself.
> 
> I guess there's an edge case here where you operate on two repositories:
> repo 1 has lz4revlog enabled
> repo 2 has lz4revlog disabled but has it listed in requires
> 
> then operating on repo 2 alone would fail, but if you operate on repo 1 
> and 2 together within the same process, things would work.

When I asked about the policy of extension enabling before posting the
first patches of this problem, I was suggested by Matt:

    We should probably strictly isolate secondary repos from the
    extensions/hooks of the primary repo

    http://selenic.com/pipermail/mercurial-devel/2012-May/040319.html

So, extensions should be disabled in repositories which disables them,
while we follow this policy.


> ... but then what happens if two repositories enable two different 
> versions of lz4revlog? Does the first one that's initialized win? 
> http://selenic.com/repo/hg/file/50d721553198/mercurial/extensions.py#l67 
> seems to indicate that that's the case. Why is that different from the 
> one enabled, one disabled case?

I have thought that this unexpected sharing may cause unexpected
result, too.

At least, Mercurial should warning message when there is precedence
extension loaded from another path.

Enabling multiple extensions in same name at a time in each
repositories itself seems to be possible. I'll try to achieve it.

----------------------------------------------------------------------
[FUJIWARA Katsunori]                             foozy at lares.dti.ne.jp