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

[Angel Ezquerra]

On Mon, Feb 10, 2014 at 1:19 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Sun, 2014-02-09 at 18:45 +0100, 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 c801bcfe8b617c7e46cdaec864271d52d04dece4
>> # Parent  b0638b5b004d575faeb363cd6028d356dc146bc2
>> subrepo: make it possible to update when a subrepo revision is missing
>>
>> Up until now, updating to a revision that refered to a missing subrepo revision
>> would fail (after trying to pull it from the remote subrepo source).
>>
>> This made it very easy to get into a situation in which it was no longer
>> possible to update to a revision in the parent repo (for example if the user
>> used MQ or rebase on the subrepo).
>>
>> With this change we now show a prompt which informs the user of the problem and
>> lets it choose what to do. By default the update will be aborted (as it did
>> before this patch. However the user will be able to update anyway if he wants
>> to.
>
> Is there anything to prevent the user from committing after this
> happens? That could be disastrous. Perhaps we can use the existing
> 'interrupted update' state to more safely allow broken checkouts (both
> for subrepos and damaged revlogs).

Currently there is nothing to prevent the user from committing after
the update. I was a bit worried about that but I did not know how to
avoid it. I think your proposal is a good one. Should we introduce a
new "unknownsubrevstate" (for example) or would you prefer that we
just reuse the existing "updatestate" (I think that its corresponding
error message does not fit this case very well)?

The usual case in which a user can get into a situation like this is
after editing draft revisions in a subrepo and (and probably in the
parent as well). In that case it is a very good idea to not allow him
to commit to avoid leaving a broken revision behind.

However I'm worried that there may be cases in which the subrepo is
truly broken (e.g. it got damaged or lost somehow) or in which it is
very hard to edit the parent repo revision to fix the problem (e.g. if
the subrepo revision that longer exists is referenced by a parent repo
revision that is the ancestor of a merge). In those cases it may be
very hard or even impossible for the user to fix the broken revision,
and disallowing commits on top of that broken revision may make things
even worse (the user might be tempted to use revert on top of another
revision or something like that). Should we try to take those edge
cases into account? I'm not saying we should, I'm just trying to
consider the worst case scenario.

Cheers,

Angel