On Fri, 13 Apr 2018 23:30:43 -0400, Matt Harbison wrote: > On Fri, 13 Apr 2018 15:10:45 -0400, Gregory Szorc > <gregory.sz...@gmail.com> wrote: > > What we may want instead is to key things off .hg/requires or a > > to-be-invented supplemental requirements-like file that declares soft > > features. localrepository.__init__ could then load trusted extensions at > > repo open time if a requirements/capability was present/requested. i.e. > > if > > you talk to an LFS server, write a semaphore somewhere into .hg/ and have > > something in core look for that and automatically load lfs if present. > > This would get you the "automatically enable LFS when talking to LFS > > servers" > > benefits. > > Sounds promising. One of the things the lfs extension is doing is writing > '[extensions]\nlfs=' to the repo's local hgrc file in a commit hook (it > should probably be handling transactions too). So it would be nice if > this was baked into the core somehow (largefiles could use exactly the > same handling, and I'm assuming narrow will be similar). It's also > manually adding to the requires file, since that doesn't seem to be > updated in exchange. > > Assuming the semaphore is persistent, it could be beneficial to load > extensions indicated by it around the normal load time (e.g., largefiles > wraps the clone command and adds extra switches). > > I'm not sure if this addresses Yuya's concern about long lived processes > though.
If the extensions to be loaded are bound to a repo, yes, that should be fine. A well-designed extension should check the repo requirements. What doesn't work in command server is to load extensions per-command basis. _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
