On 2/26/22 05:06, Manuel Jacob wrote:
# HG changeset patch
# User Manuel Jacob <m...@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
_______________________________________________
kallithea-general mailing list
kallithea-general@sfconservancy.org
https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
