Revset-based implementation of log command

[Patrick Mézard]

Le 17/04/12 18:36, Patrick Mézard a écrit :
> Le 16/04/12 20:06, Matt Mackall a écrit :
>> On Fri, 2012-04-13 at 22:15 +0200, Patrick Mézard wrote:
>>> Le 12/04/12 22:49, Matt Mackall a écrit :
>>>> On Thu, 2012-04-12 at 21:52 +0200, Patrick Mézard wrote:
>>>>> [3] could be fixed by turning revset.match() into a
>>>>> generator. It is not clear which revset functions can operate
>>>>> on a "subset" generator rather than a list but the simple
>>>>> ones like user() definitely can. Also, I have no idea how
>>>>> much overhead this will add compared to the list version.
>>>> 
>>>> Any predicate can choose to turn its args from generators into
>>>> lists, if need be, so it shouldn't be all that hard
>>>> architecturally to get some of this working.

[...]

>> Which brings us back to not(merge()). Evaluating this in the
>> current revset code means visiting the entire index and checking
>> for second parents, but that's quite cheap, and it seems worth
>> doing all the work up front in any case. But for not(user(x)), we
>> want to go the independent route because the subexpression is
>> expensive.
>> 
>>> orset() cannot be turned into a filter in the general case. Here,
>>> we often have an additional property: input revisions are sorted
>>> by value. In this case, we can write an orset() version computing
>>> both "or" branches on "subset" (instead of subset and (subset -
>>> "first branch output")) and use the revision order to merge back
>>> the iterable, then preserving the order again. Again, this would
>>> be a dedicated revset.
>> 
>> I don't see why this can't be an iterable. If we do 'x or y', we
>> simply need to yield all the elements of x before we start yielding
>> element in 'y - x'. And that just means we need to remember the
>> elements of we've seen of x as we go. Even if either set is a
>> non-independent revset.
> 
> Right, and in fact I did this.
> 
> But for log command I need another property I stupidly removed from
> my previous post: I need orset() to preserve input order. If not,
> stuff like "--user foo --user bar" returns two concatenated stripes
> of history which is a regression, unless we sort at the end and lose
> the iterable property again. That is what my more constrained version
> deals with.

I should have said "improved the latency" as it turns it into max(latency to predicate1, latency to predicate 2), not min(latency to predicate1, latency to predicate 2).

--
Patrick Mézard