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

[Matt Mackall]

On Sat, 2015-10-17 at 09:39 +0200, Adrian Buehlmann wrote:
> 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.

It's probably mostly a matter of the structure of hg.py:clone today:
it's already created the repo before the pull begins. We could be lazy
about that, but it's a bit complicated.

The locking issue I alluded to is that a second process can start doing
work in this repo, adding files and starting a commit. If the commit
reads the requires file before it's created, it will be misinformed
about where the store lock ought to be!

To fully close this race, the .hg directory has to be created with a
temporary name, the requires file written into it, and then renamed
to .hg.

But even all of this doesn't mean we never have to upgrade requirements:
we already know largefiles might be introduced at any point in a
project's history and thus force a new requirement.

-- 
Mathematics is the supreme nostalgia of our time.