[PATCH 0 of 3 RFC] Hidden changesets and usability

[Angel Ezquerra]

On Thu, Aug 8, 2013 at 9:48 AM, Dan Villiom Podlaski Christiansen
<danchr at gmail.com> wrote:
> Hi,
>
> This series is probably incomplete and needs a bit of discussion;
> hence the RFC tag.
>
> From my perspective, one of the annoying parts of working with the
> evolve extension and histedit compared to MQ is the lack of consistent
> identifiers for in-progress changesets, similar to MQ's patch
> names. Typically, I'll work on something, do a histedit or evolve, and
> want to return. If I want to return to where I was, I then have to
> enter either the new hash or revision somehow; I can't just search my
> shell history or reuse any info I could obtain *before* doing the edit
> round.
>
> Currently, when a user enter an identifier -- whether hash or revision
> -- that refers to a hidden changeset, they're told that such a
> revision doesn't exist. This isn't terribly helpful, and even
> misleading in a sense: the revision plainly exists; it's merely
> hidden. If the user really wants to, they can often recover it.
>
> So, the first step is it tell the user that something is hidden; the
> first patch in this series does that.
>
> Then, how do we identify revisions? It's worth noting that obsolete
> changesets may exist in one of three states:
>
> 1) The changeset has no successors; it was killed.
> 2) The changeset has one and only one live successor.
> 3) The changeset has more than one successor.
>
> #1 and #3 should be presented to the user as an error. #3 preferably
>  with a list of choices they might refer to.
>
> I believe the most common case is #2, and it also has an extra
> attribute; hidden changesets that have one and only one live successor
> uniquely identify that successor. Furthermore, they will always refer
> to that successor (or its successor) unless they become divergent.
>
> The idea is to redirect a hidden changeset to refer to its one
> successor, if possible; the third patch implements a proof-of-concept
> of that.
>
> I mainly wanted to send the patch here for feedback on the concept. Is
> this something suitable for Mercurial core? I'll probably change the
> HTTP status codes and web error messages; they're not set in stone,
> but mainly prove that we can distinguish between the different
> cases.
>
> (I imagine the CLI equivalent is better suited to the evolve
> extension.)

I think this is a cool (and insightful) idea which may have a very
nice side effect related to subrepos.

Currently if you use evolve to amend a revision on a subrepo you will
"break"  the parent repo, because the commints on the parent repo will
not find the revision on the subrepo that they refer to.

When a parent repo is "broken" due to a missing subrepo it is quite
hard to fix, because it is sometimes not even possible to update to
the revision that you want to fix.

With this (or a similar) change mercurial could still update to the
corresponding revision, possibly showing an error or warning message.
Additionally, this info could be used to automatically amend the
parent revision so that points to the proper successors on the
subrepos.

Cheers,

Angel