[PATCH] revset: add the 'subrev' symbol

[Matt Harbison]

On Wed, 24 Jun 2015 21:34:54 -0400, Pierre-Yves David  
<pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 06/24/2015 02:55 PM, Matt Harbison wrote:
>> # HG changeset patch
>> # User Matt Harbison <matt_harbison at yahoo.com>
>> # Date 1435179910 14400
>> #      Wed Jun 24 17:05:10 2015 -0400
>> # Node ID 74b79bc0f22824f1858750f987915671e3ecf1b9
>> # Parent  1de5b35cecd32a4691d0542d03348c13e5813c95
>> revset: add the 'subrev' symbol
>>
>> This finds revisions in the outer repo that track a named revision of a  
>> subrepo.
>> It allows for a partial match, as long as the named revision is at  
>> least as long
>> as the 'shortid' form defined by the subrepo.  Allowing shorter strings  
>> seems
>> risky- the user may specify a "{rev}" value, and not realize it only  
>> partially
>> matches on a full "{node}".
>>
>> A more general query is to figure out what revisions in the outer repo  
>> track the
>> named revision, _or a descendant of it_.  This would make it much  
>> easier to
>> figure out where a subrepo change becomes visible if there are a series  
>> of
>> subrepo changes, with one lockin commit to the outer repo.  But that  
>> looks much
>> more complicated.  If that makes sense to implement in this revset in  
>> the
>> future, we can probably do so by adding an argument to the revset that  
>> controls
>> the behavior, similar to the -key arg to sort().
>
> What I would expect from such feature is
>
>    hg log --rev 'subrepo([pattern], revs="anyrevset")'
>
> 1) This would allow to select the subrepo we are targeting (which have  
> usability and performance benefit).
>
> 2) having revset would allow any kind of operation (including revision X  
> or descendant to be done).
>
> Doing (1) seems simple. Doing (2) is a bit tricker because as far as I  
> know, the subrepo is not necessarly checked out. So we should maybe  
> design the API so it could support any revsets but only support hex-node  
> for now.
> We can probably use revset now if the repo is checkout in the repository  
> or if the subrepo cache is operational. But supporting (2) seems a bit  
> premature(as this changeset already points).
>
> What do you think about (1) (reusing the subrepo revset?

The only reason I didn't add this to the existing subrepos() is that I  
don't see a precedent for how to skip the first parameter and specify the  
second.  I assume the 'revs=' bit is for clarity here, not part of the  
actual query that needs parsing?  So would that mean needing to support a  
'*' in the first parameter?  I figured this would be faster than adding to  
all of the status and matcher code in subrepos(), but don't have any  
numbers to back that up.  I also assume that every id is unique across all  
subrepos.

After coding it, this query will look at any revision that references a  
subrepo.  The subrepo() revset only looks for add/modify/remove changes to  
the subrepo.  This need to specify 'AMR' for subrepos seems to dovetail  
with the template discussion with Yuya.

I do like the idea of being able to pass a subrepo focused revset.  The  
partial matching I've done here is kludgy.  But I don't know what those  
revsets would mean for git and svn subrepos.  I guess those don't matter  
until someone feels like implementing a revset engine for them.

It might also help for something like  
http://bz.selenic.com/show_bug.cgi?id=4445 and the other bug I referenced  
there.