[PATCH stable] hg: use correct start / stop indices when slicing revisions

[Mads Kiilerich]

On 2/26/22 05:06, Manuel Jacob wrote:
> # HG changeset patch
> # User Manuel Jacob <me at manueljacob.de>
> # Date 1645848272 -3600
> #      Sat Feb 26 05:04:32 2022 +0100
> # Branch stable
> # Node ID 84c94153376698aa028c03dbad1fc0dcf6f081ed
> # Parent  397f73d1cdd4b39c9c17bb8d45592e866fcab88c
> hg: use correct start / stop indices when slicing revisions
>
> Previously, the indices where determined on self.revisions, which contains all
> visible revisions in the repository. However, in some cases, these indices were
> used on a list which had the items at different positions.


I assume this is related to two different concepts:

Kallithea has this stupid non-scalable but convenient list of all 
revisions. It is used when paging, when finding next/previous changeset 
... and scanned linearly. These concepts and uses are questionable - the 
linearization of the repo is rarely really useful to users. It is better 
to walk the DAG and visit parents/children. I think it would be nice to 
get rid of self.revisions and do things differently. I think that is the 
essence of the "very much a hack" comment. But for now, we have the list 
of all visible revisions.

Mercurial also has the revision numbers, which mainly is a convenient 
implementation detail that however sometimes breaks down - for example 
when revisions are private. I don't think Kallithea these revision 
numbers except when doing low level DAG walking.

Is the real problem that Kallithea in some cases will use Mercurial 
revision numbers when it shouldn't? Or how/where do you see "items at 
different positions"? Can you say more about the problematic cases you see?

Ideally, we should add test suite coverage for your problem. But a 
manual/automated reproducible test case could also help for now.


> With this change, the indices are always determined on the list which is sliced
> with these indices.
>
> I didn’t fully understand the comment that I moved. If it doesn’t make sense to
> move it, I’d happy to send a new patch series removing or changing the comment
> before or after this change.


The comment came from 98d235e28078 when Mercurial started encapsulating 
the internal revision list so private revisions could be hidden.

I think it still applies where you put it.


/Mads