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

[Dmitry Gutov <dgutov@yandex.ru>]

On 12/16/2015 01:53 AM, Andy Moreton wrote:

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

So it's a bug in the current implementation, even without hidden revisions?

I'll try to remember this next time someone tells me about 
user-friendliness of numeric revisions. :)

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

If there's a direct counterpart to 'git rev-parse 59951^', it would be 
handy here.

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

So, what if we don't pass "--hidden" to this command? Will `ancestors' 
error out upon encountering a hidden revision, or will they skip to the 
first visible one?

In the latter case, there's no need to check 'not hidden()', and the 
compatibility problem can be solved like that.