[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#22032: 24.3; VC doesn't handle hg hidden revisions
From: |
Andy Moreton |
Subject: |
bug#22032: 24.3; VC doesn't handle hg hidden revisions |
Date: |
Tue, 15 Dec 2015 23:53:08 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (windows-nt) |
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
- bug#22032: 24.3; VC doesn't handle hg hidden revisions,
Andy Moreton <=