[PATCH 1 of 5 requirements-tidy] localrepo: add requirements helper functions

Pierre-Yves David pierre-yves.david at ens-lyon.org
Wed Oct 14 17:12:24 CDT 2015



On 10/14/2015 08:58 PM, Augie Fackler wrote:
> On Tue, Oct 13, 2015 at 01:48:13PM -0500, Matt Mackall wrote:
>> On Thu, 2015-10-01 at 15:47 -0700, Gregory Szorc wrote:
>>> On Thu, Oct 1, 2015 at 3:20 PM, Matt Mackall <mpm at selenic.com> wrote:
>>>
>>>> On Thu, 2015-10-01 at 12:29 -0700, Gregory Szorc wrote:
>>>>> # HG changeset patch
>>>>> # User Gregory Szorc <gregory.szorc at gmail.com>
>>>>> # Date 1443725945 25200
>>>>> #      Thu Oct 01 11:59:05 2015 -0700
>>>>> # Node ID a6ba4ec0ac210f86459ae7da0a8843d6132a0d12
>>>>> # Parent  97dc6ab42aad232c73180dee648685c26662230b
>>>>> localrepo: add requirements helper functions
>>>>>
>>>>> Currently, various consumers of requirements call "private" functions on
>>>>> localrepository to update the requirements set. This breaks an API
>>>>> contract. Furthermore, consumers are inconsistent in their handling of
>>>>> requirements updating, forgetting to call _applyopenerreqs().
>>>>
>>>> I'm not particularly excited about the idea of making it easy for things
>>>> to add to requirements after repository creation, and even less excited
>>>> about removals. If the requirement is not -actually a permanent
>>>> attribute that's required to read a repo- ... then maybe it's not
>>>> actually a requirement.
>>>>
>>>> For instance: largefiles. Switching on largefiles is permanent in that
>>>> you can't switch it off without rewriting history. You should be really
>>>> sure you want to turn it on because you can effectively never turn it
>>>> off again.
>>>>
>>>
>>> That's fair.
>>>
>>> This series was mostly cosmetic cleanup and not critical to my end goal of
>>> modernizing stream clones. Are there any parts worth salvaging or should I
>>> throw it all away?
>>
>> I think everything but the post-init write access seemed reasonable.
>
> So, this is actually now screwing me for treemanifests. In particular,
> the repo is already initialized when we start applying the changegroup
> to it, but as part of receiving the changegroup we find out we're
> getting treemanifests. Thoughts?

Should the repository decide if it want to use tree manifest (or not) at 
init time? And request tree manifest to the server if it does so?

-- 
Pierre-Yves David


More information about the Mercurial-devel mailing list