[PATCH 04 of 10] localrepo: move ui loading to baselocalrepository

Kevin Bullock kbullock+mercurial at ringworld.org
Fri Feb 24 11:13:40 EST 2017


> On Feb 23, 2017, at 11:15, Jun Wu <quark at fb.com> wrote:
> 
> Excerpts from Yuya Nishihara's message of 2017-02-23 22:05:24 +0900:
>> On Wed, 22 Feb 2017 20:27:39 -0800, Jun Wu wrote:
>>> Excerpts from Kevin Bullock's message of 2017-02-22 20:31:14 -0600:
>>>> There's another alternative we might consider: can we move all of the
>>>> "side effects" out of the localrepository class entirely? That is, instead
>>>> of resorting to inheritance, could we create a lower-level "repo storage"
>>>> class that has enough logic to make vfs and svfs available, but doesn't
>>>> call reposetup()?
>>> 
>>> That's what I'm doing - moving "extensions.loadall()" out from
>>> localrepository.__init__, and together with chg refactoring,
>>> extensions.extensions will eventually return a empty list so things could be
>>> seen as side-effect free.
>> 
>> Perhaps what Kevin suggests would be similar to my vague idea. Instead of
>> introducing doubtful inheritance tree, can we create a layer that has vfs,
>> svfs, etc., and have localrepo delegate storage operation to it?
>> 
>> https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-February/092552.html 
>> 
>> Maybe that would require more changes than using inheritance, but would be
>> less complex.
> 
> vfs is independent. But svfs depends on repo requirements and sharedpath.
> Will that layer include requirements and sharedpath too? If so, it will
> be similar to the "baselocalrepository" here.

Yeah, I think you're including the right things in baselocalrepository; I just think we should make it a collaborator with localrepo, instead of a base class.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock



More information about the Mercurial-devel mailing list