Patchwork subrepo: make it possible to update when a subrepo revision is missing

login
register
mail settings
Submitter Angel Ezquerra
Date Feb. 9, 2014, 5:45 p.m.
Message ID <c801bcfe8b617c7e46cd.1391967935@Angel-PC.localdomain>
Download mbox | patch
Permalink /patch/3522/
State Deferred
Headers show

Comments

Angel Ezquerra - Feb. 9, 2014, 5:45 p.m.
# HG changeset patch
# User Angel Ezquerra <angel.ezquerra@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.
Matt Mackall - Feb. 10, 2014, 12:19 a.m.
On Sun, 2014-02-09 at 18:45 +0100, Angel Ezquerra wrote:
> # HG changeset patch
> # User Angel Ezquerra <angel.ezquerra@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).
Angel Ezquerra - Feb. 10, 2014, 7:07 a.m.
On Mon, Feb 10, 2014 at 1:19 AM, Matt Mackall <mpm@selenic.com> wrote:
> On Sun, 2014-02-09 at 18:45 +0100, Angel Ezquerra wrote:
>> # HG changeset patch
>> # User Angel Ezquerra <angel.ezquerra@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

Patch

diff --git a/mercurial/subrepo.py b/mercurial/subrepo.py
--- a/mercurial/subrepo.py
+++ b/mercurial/subrepo.py
@@ -734,6 +734,13 @@ 
                     _('revision %s in subrepo %s is hidden\n') \
                     % (revision[0:12], self._path))
                 repo = urepo
+        elif revision not in repo:
+            choice = repo.ui.promptchoice(
+                _('target revision (%s) in subrepo %s is missing\n'
+                  'do you want to continue with the update (yN)? '
+                  '$$ &Yes $$ &No') % (revision[0:12], self._path), default=1)
+            if choice == 0:
+                return
         hg.updaterepo(repo, revision, overwrite)
 
     @annotatesubrepoerror