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

[Andy Moreton <andrewjmoreton@gmail.com>]

On Wed 16 Dec 2015, Dmitry Gutov wrote:

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

Yes.

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

You mean like the "hg id" line in the example above ?

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

No idea - I haven't used this new feature, or spent the time to
construct a test repo with hidden revisions to find out.

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

Perhaps - but it needs to be tested to find out.

    AndyM