Changing repo requirements (was: Re: [PATCH 1 of 5 requirements-tidy] localrepo: add requirements helper functions)

[Adrian Buehlmann]

On 2015-10-16 19:50, Matt Mackall wrote:
> On Fri, 2015-10-16 at 13:44 -0400, Augie Fackler wrote:
>> On Fri, Oct 16, 2015 at 1:17 PM, Matt Mackall <mpm at selenic.com> wrote:
>>> On Wed, 2015-10-14 at 15:58 -0400, 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:
>>>>>> 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?
>>>
>>> My point is not that you shouldn't be able to change requirement, but
>>> that -it should not be this easy-. Greg's patches are way too friendly
>>> to this and people who just read his API will assume it's totally ok to
>>> slap on new requirements whenever it's convenient without considering
>>> the attendant headaches.
>>
>> *nod*. I think for both our needs it'd be fine to make it possible to
>> change requirements only on repositories that are empty (or were
>> before the current transaction). Would that be reasonable at least for
>> now?
> 
> Sure.
> 

A fun fact (which I think Matt has already pointed out elsewhere in the
past) is, that the simplest empty repository is one which has nothing
but an empty .hg directory:

    $ mkdir a
    $ cd a
    $ mkdir .hg
    $ hg verify
    repository uses revlog format 0
    checking changesets
    checking manifests
    crosschecking files in changesets and manifests
    checking files
    0 files, 0 changesets, 0 total revisions
    $ hg sum
    parent: -1:000000000000 tip (empty repository)
    branch: default
    commit: (clean)
    update: (current)

This is the very first repository format, which doesn't even have a
requires file. Which of course current Mercurial still can read and
write (which is not recommended to be used nowadays for committing to).

A separate question remains, why Gregory and Augie need a preexisting
(empty) repo as a precondition for their particular use cases of interest.

If you'd start with no repository at all, you could avoid having to
worry about changing the requires file.