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