[PATCH 5 of 9] revset: abort the query when there is no revision for "rev()" (BC)

[Augie Fackler]

On Tue, Mar 31, 2015 at 8:08 AM, Matt Mackall <mpm at selenic.com> wrote:
> On Mon, 2015-03-30 at 14:19 -0400, Augie Fackler wrote:
>> On Tue, Mar 31, 2015 at 01:31:52AM +0900, FUJIWARA Katsunori wrote:
>> > At Mon, 30 Mar 2015 14:05:45 +0900,
>> > Yuya Nishihara wrote:
>> > >
>> > > On Mon, 30 Mar 2015 03:34:27 +0900, FUJIWARA Katsunori wrote:
>> > > > # HG changeset patch
>> > > > # User FUJIWARA Katsunori <foozy at lares.dti.ne.jp>
>> > > > # Date 1427653752 -32400
>> > > > #      Mon Mar 30 03:29:12 2015 +0900
>> > > > # Node ID f9e9783d4f10af2974d77dbfaacd217f24fd3035
>> > > > # Parent  efa05b47238ba2a0bca69cd40b8e2e1aed3a2cf2
>> > > > revset: abort the query when there is no revision for "rev()" (BC)
>> > > >
>> > > > Before this patch, "REV" and "rev(REV)" differ from each other:
>> > > >
>> > > >     target      REV          rev(REV)
>> > > >     ----------- ------------ ------------
>> > > >     known       pass         pass
>> > > >     hidden      abort (*1)   pass (=> empty set)
>> > > >     unknown     abort        pass (=> empty set)
>> > > >
>> > > >     (*1) abort with "use --hidden" hint
>> > > >
>> > > > For equivalence between them, "rev(REV)" should abort the query for
>> > > > hidden or unknown revisions, even though this may break backward
>> > > > compatibility for existing tools, which expect that "rev()" doesn't
>> > > > abort the query in any cases.
>> > >
>> > > I thought about it before, but because rev() didn't raise error for 3 years,
>> > > I'm afraid that there would be some tools that rely on the existing behavior.
>> >
>> > What about introducing new predicates "revnum()" (and "hashid()") or
>> > so for strict behavior ? (should we make "rev()"/"id()" deprecate, too ?)
>>
>> I'd be in favor of something like that iff we can't declare the
>> no-args behavior of rev() and id() to be bugs, which would be my
>> strong preference. cc'ing mpm so he can weigh in.
>
> "no-args behavior"?

I worded things poorly, but also completely misread the table above. I
had (wrongly) thought this was making it so that no-arguments-passed
rev() and id() would be saner by returning errors, but it's actually
about an argument being passed that's somehow invalid being allowed to
slip by.

I'm no longer a fan of where this series is going, both because it
seems wrong and because I can't fathom a usecase.

>
> We seem to be preparing to change the behavior with explicitly naming
> hidden changesets, but no one wants to tell me about it.

Huh? (I'm legitimately confused here, but I also haven't read -devel
since work yesterday. If there's some sort of plan about that, I'm
unaware of it.)