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

[Angel Ezquerra]

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...

- 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.

Cheers,

Angel