[PATCH V2] subrepo: make it possible to update when a subrepo revision is missing

Matt Mackall mpm at selenic.com
Mon Jun 9 17:40:51 CDT 2014


On Sun, 2014-06-08 at 01:53 +0200, Angel Ezquerra wrote:
> On Fri, May 30, 2014 at 12:35 AM, Matt Mackall <mpm at selenic.com> wrote:
> > On Sun, 2014-05-04 at 17:39 +0200, Angel Ezquerra wrote:
> >> # HG changeset patch
> >> # User Angel Ezquerra <angel.ezquerra at gmail.com>
> >> # Date 1391950775 -3600
> >> #      Sun Feb 09 13:59:35 2014 +0100
> >> # Node ID ed7ad31bca48522062689a457559d25e802ef59e
> >> # Parent  cadad384c97c7956c98f3c9b92d8cc40fa16d93b
> >> subrepo: make it possible to update when a subrepo revision is missing
> >>
> >> Up until now, updating to a revision that referred to a missing subrepo revision
> >> would fail (after trying to pull it from the remote subrepo source).
> >
> > http://mercurial.markmail.org/thread/ujnahcp47by4gokf
> >
> > Broken checkouts are not a subrepo-specific problem. So if you want to
> > add a "broken checkout" state, it must not be subrepo-specific. This is
> > why I pointed you to the closest thing we currently have to a broken
> > checkout state.
> >
> > And again: prompts = unloved. I'd rather have a (non-subrepo-specific)
> > command line flag to update to allow checking out a broken state.
> 
> OK, I've re-read your original reply and it seems that I missed that
> you very clearly suggested introducing a non subrepo specific state.
> Sorry about that.
> 
> I've been thinking about this a little. I have a couple of questions:
> 
> - Would you prefer that I introduced a new state (e.g.
> brokencheckoutstate or incompleteupdatestate) or that I reuse the
> existing "updatestate"? They are not exactly the same, but they are
> quite similar...

I don't have a strong opinion here. An interrupted checkout is just a
subset of broken checkouts.

> - Would you like for the new update flag to be called --force? It
> would basically mean "go ahead, try to update and do as many of the
> update actions as you can, ignoring errors". For now the flag would
> limit its effect to subrepo update failures (and possibly not even
> cover all subrepo types at first), but it could later be expanded to
> allow for other types of errors.

Hmm. If we call it --force, users will try to use --force to bypass the
other non-integrity errors and complain that doesn't work. If we make it
work, they'll use --force habitually and then be surprised when they
have a sad. Such people deserve to have a sad, but that's perhaps not
how we should design it.

We might want something like:

    --broken      ignore integrity errors (and disable commit)

And then if people complain that --broken made them sad, we can make
them stand in the corner.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list