[PATCH 04 of 10] localrepo: move ui loading to baselocalrepository
Kevin Bullock
kbullock+mercurial at ringworld.org
Fri Feb 24 16:13:40 UTC 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