We drop iterrevs which are not needed anymore. The know head are never a
descendant of the updated set. It was possible with the old strip code. This
simplification make the code easier to read an update.
We never use the node of new revisions unless in the very specific case of
closed heads. So we can just use the revision number.
So give another handfull of percent speedup.
Was the behavior correct and the description wrong so it should be updated as
in this patch? Or should the code work as the documentation says?
Both ways could make some sense ... but none of them are obvious in all cases.
One place where it currently cause problems is when the current revision has
another branch head that is closer to tip but closed. 'hg rebase' refuses to
rebase to that as it only see the tip-most unclosed branch head which is the
current revision.
/me kind of likes named branches, but no so much how branch closing works ...
This is a step towards breaking an import cycle between revset and
repoview. Import cycles happened to work in Python 2 with implicit
relative imports, but breaks on Python 3 when we start using explicit
relative imports via 2to3 rewrite rules.
Since repoview in 2.5 we do not make special call to `branchmap` when stripping.
We just recompute the branchmap from a lower subset that still has valid
branchmap. So I'm dropping this dead code.
It was unused. note how it is only extended if the list is empty. So it's always
empty at the end.
We could try to fix that, however this would part of the code is to be removed
in the next changeset as we do not run `branchmap` on truncated repo since
`repoview` in 2.5.
We have a very handy assert at the ends of `branchmap.updatecache` that check
the resulting branchmap is actually valid.
I know we do not like assert in mercurial but this one is very handy for
debugging. There is really not reason for `branchmap.updatecache` to have this
kind of issue but this happened and handful of time during the development of
this or introduction of other related feature. I advice to keep it around until
we are a bit more confident with the new code.
Creation of changectx objects is very slow, and they are not very
useful. We are going to drop them. The first step is to change the
function argument type.
Filtered repository are *subset* of unfiltered repository. This means that a
filtered branchmap could be use to compute the unfiltered version.
And filtered version happen to be subset of each other:
- "all() - unserved()" is a subset of "all() - hidden()"
- "all() - hidden()" is a subset of "all()"
This means that branchmap with "unfiltered" filter can be used as a base for
"hidden" branchmap that itself could be used as a base for unfiltered
branchmap.
unserved < hidden < None
This changeset implements this mechanism. If the on disk branchcache is not valid
we use the branchcache of the nearest subset as base instead of computing it from
scratch. Such fallback can be cascaded multiple time is necessary.
Note that both "hidden" and "unserved" set are a bit volatile. We will add more
stable filtering in next changesets.
This changeset enables collaboration between no filtering and "unserved"
filtering. Fixing performance regression introduced by 7bff5f37cb97
If we want branchcache of different filter to collaborate, they need a simple
way to copy each other. This will ensure that each filtered have no side effect
on other filter level cache.
Nobody overwrite the `_cacheabletip` any more. We always update the cache for
the whole repo and write it to disk (or at list try to). The `updatecache` code
is simplied to remove the double phase logic associated with _cacheabletip.
The `_branchcache` attribute is turned into a dictionary. Key are filter name and
value is a `branchcache` object. Unfiltered version is cached as `None` filter.
The attribute is renamed to `_branchcaches` to avoid confusion with the previous
one. Both old and new contents are dictionary even if their contents are
different. I prefer possible extension code to crash right away instead of just
messing the wrong dictionary.
As all different caches work isolated to each other, this code keeps the
previous behavior of using the unfiltered cache we nothing is filtered. This
is a cheap way to have cache collaborate and nullify potential impact in the
default case.
Now that we have a third part for the cache key we need to write and read it on
disk. It is only written when there is filtered revision. This keep the format
compatible with older version.
Notes that, at this state, filtered repository does not use any disk caches yet.
Tracking tipnode and tiprev is not enough to ensure validaty of the cache as
they do not help distinguish a cache that ignored various revisions below
tiprev.
To detect such difference, we build a hash of all ignored revisions. This hash
is then used when checking the validity of a cache for a repo.
With revision filtering the effective revision number of "tip" may be lower than:
len(changelog) - 1
We now use a more correct version preventing useless writing on disk in some
case.
In several place, We check if a branchcache is still valid regarding the current
state of the repository. This changeset puts this logic in a method of the object
that can be reused when necessary.
A branch map is considered valid whenever it is up to date or a strict subset of
the repository state.
The change will help making branchcache aware of filtered revision.
The change in keyword is expected. the branch cache is actually invalid after
the amend. The previous check did not detected it.
The update function have all necessary data to keep the branchcache key
up to date with its value.
This saves assignment to the cache key that each caller of update had to do by
hand.
The strip case is a bit more complicated to handles from inside the function but
I do not expect any impact.
Value and key of branchcache would benefit from being hold by the same object.
Moreover some logic (update, write, validation) could be move on such object.
The creation of this object is the first step toward this move. The result will
clarify branchcache related code and hide most of the detail in the class
itself. This encapsulation will greatly helps implementation of branchcache for
filtered view of the repo.
This is the foundation stone for an extraction of branches map logic from local
repository class. Most of the branches map logic have very few caller and
therefor does not fit in the current criteria for code held by the localrepo
class. Important change will be made to this code in relation with revision
filtering. So we extract it in a dedicated module before adding additional
complexity.
Follow up commit do the actual code movement.
