[PATCH 2 of 2] requires: write requires file on commit

Drew Gottlieb drgott at google.com
Mon May 4 17:30:36 CDT 2015


Alright, let's drop this patch for now. I'd still like to see patch 1 of 2
queued though.

>From IRC it seems a possible way forward can be having a command like 'hg
migrate' to handle migrations to new formats such as manifestv2 or
treemanifests. If such a command were created, the requires write could
happen then. Obviously, whether and how we have such a command is a
considerably larger discussion.

On Mon, May 4, 2015 at 1:53 PM Matt Mackall <mpm at selenic.com> wrote:

> On Mon, 2015-05-04 at 13:27 -0500, Drew Gottlieb wrote:
> > # HG changeset patch
> > # User Drew Gottlieb <drgott at google.com>
> > # Date 1429641493 25200
> > #      Tue Apr 21 11:38:13 2015 -0700
> > # Node ID 85c369520dd97bad369a0c4b924597f9e720077b
> > # Parent  3f86e3b2548def52732e1f782e89297db8075e8b
> > requires: write requires file on commit
> >
> > Writing the requires file on commit makes it possible for changes to a
> > repo's config to enable features that affect the repo's requirements. An
> > example of this would be enabling manifestv2 in the future, which would
> then
> > have future commits be written with the new manifest format, making it
> > necessary for the requires file to indicate this.
> >
> > This change also modifies test-inherit-mode to expect the requires file's
> > mode to inherit from the store's mode after a commit. Previously, it only
> > inherited from the store's mode on repo init, and the test assumed it
> would
> > never be touched after this point.
>
> I can't say I'm excited about this. Today, changing the requirements of
> a repository is a big deal, and is intentionally done only at creation
> time[1]. Among other things, it means people can create a repo with an
> old Mercurial and be assured of continuing compatibility with that
> version. Very important for repositories on shared disk.
>
> Writing it unconditionally (and non-atomically!) on every commit is just
> inviting people/extensions to break this. I think it should instead
> continue to be an extension-specific headache.
>
> [1] Largefiles breaks this rule; largefiles breaks everything and should
> not be looked to as a role model.
>
> --
> Mathematics is the supreme nostalgia of our time.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150504/ddc1527d/attachment.html>


More information about the Mercurial-devel mailing list