bug#22032: 24.3; VC doesn't handle hg hidden revisions

[Andy Moreton <andrewjmoreton@gmail.com>]

On Sat 28 Nov 2015, Dmitry Gutov wrote:

> Hi Glenn,
>
> Please keep the bug address in Cc. I'm reproducing the entirety of your email
> here for posterity.
>
> On 11/28/2015 05:07 PM, Glenn Hutchings wrote:
>
>> Thanks for the quick response.  I've been doing a bit more digging for
>> info about this, and think I've figured out exactly how I got into the
>> situation.  There's an experimental set of features called Changeset
>> Evolution <https://www.mercurial-scm.org/wiki/ChangesetEvolution> that
>> modifies the way mercurial rewrites history: instead of stripping a
>> changeset, it marks it 'obsolete'.  Looks like these features were
>> introduced at version 2.9, but by default none of them are used by the
>> core mercurial commands.  But a recent extension called Evolve
>> <https://www.mercurial-scm.org/wiki/EvolveExtension> does use it.  If
>> you enable that extension, and then perform a "commit --amend", instead
>> of updating the head changeset, it creates a new one and makes the
>> previous one obsolete (and 'hidden' by default in the change log).
>>
>> Long story short: the gap in rev numbers only occurs if you enable the
>> 'evolve' extension (or another which uses the changeset-evolution
>> features) and use a history-modifying command.  I recently tried the
>> extension out, which is when I came across the bug.
>
> I see.
>
>>> Is there a reason why we wouldn't want to use that argument and just
>>> always display them?
>>>
>>
>> Well, the hidden revs are really only used internally, and shouldn't be
>> seen by users.
>>
>>> Would calling 'hg diff --hidden' help?
>>>
>>
>> Unfortunately not -- that would only do a diff between the current rev
>> and the internal hidden one.  Not what the user really wants.
>
> That makes sense.

This problem with revision IDs also accurs if the repo contains named
branches. in that case the numerically previous revision may be on a
different branch, resulting in a meaningless diff that is slow to
compute.

For example (from a non-public repo with named branches), where rev
59951 and rev 59950 are on different named branches:
  $ hg diff -r59951 -r59950 | wc -l
  88188
  $ hg diff -r59951 -r59951^ | wc -l
  70
  $ hg id -n -r59951^
  59925

The first example diffs agaist the previous revision ID (which is on a
different branch), and produces large and useless diff output. The second
example diffs against the (first) parent, and is what is actually wanted.

>> I managed to come up with this, using mercurial's 'revset' feature:
>>
>>     hg id --hidden -n -r 'first(X:0 and not hidden())'
>
> Thanks. Please try this definition and see if it resolves the problem:
>
> (defun vc-hg-previous-revision (_file rev)
>   (let ((newrev (1- (string-to-number rev))))
>     (when (>= newrev 0)
>       (with-temp-buffer
>         (vc-hg-command t 0 nil
>                        "id" "--hidden" "-n" "-r"
>                        (format "first(%d:0 and not hidden())" newrev))
>         ;; Trim the trailing newline.
>         (buffer-substring (point-min) (1- (point-max)))))))
>
>> This says to look at all non-hidden revs from X down to zero, choose the
>> first one, and print its numeric rev number.  If the current rev is X+1,
>> that gives the first previous non-hidden rev.  But I'm sure there must
>> be a better way, without having to examine all previous changesets.
>
> If you anticipated that we'd have to make one process call per revision, then
> I think the above definition does better.

To also work with named branches, something like this (untested) would be better:
    (format "last(ancestors(%d) and not hidden())" newrev)

>> Given the experimental nature of all this evolution stuff, I'm inclined
>> to think that it's not all that urgent a problem to resolve right now.
>> But if it ever becomes part of core mercurial, it's something to bear in
>> mind.
>
> Indeed, it seems there's no hurry. On the other hand, I don't expect much harm
> from installing the new vc-hg-previous-revision definition either: it works
> fine with the version of Mercurial installed on my machine (3.4), although in
> all cases I've tried it basically returned the revision passed to it as X.
>
> If it would cause earlier versions of Mercurial to error out, however, that
> would be a reason to hold off on it.

Indeed - even after the evolution stuff has matured further, there will
still be a large population of machines that are running older versions
of Mercurial, and will not understand the "hidden()" predicate.

    AndyM