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

[Dmitry Gutov]

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.

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

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