At this moment, the cache is invalid, and will be thrown away.
Later the strip function will call the `localrepo.destroyed` method
that will update the branchmap cache.
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.
The previous code was writing it to a non existent `branchcache` attribute. We
now write is to the proper `_branchcache` attribute and initialize the
`_branchcachetip` at the same time.
We keep writing it to disk, the previous code had this part right.
The `_updatebranchmap` method on repo does not need to be filtered as all
callers are already handling filtering themself.
The fact it is filtered may had even lead to buggy behaviors, but by chances the method
make very sparse use of the repo object.
The current _branchtags method is a remnant of an older, much larger function.
Its only remaining role is to help MQ to alter the version of branchcache we
store on disk. As MQ mutates the repository it ensures persistent cache does not
contain anything it is likely to alter.
This changeset makes explicit the stable vs volatile part of repository and
reduces the MQ specific code to the computation of this limit. The main
_branchtags code now handles this possible limit in all cases.
This will help to extract the branchmap logic from the repository.
The new code of _branchtags is a bit duplicated, but as I expect major
refactoring of this section I'm not keen to setup factorisation function here.
The `hiddenrevs` cache is volatile too (It use content from `obscache`). When
unsure it is invalidated when necessary. In a near future, the cache will
probably be moved to `revsfiltercache`
Recomputing the filtered revisions at every access to changelog is far too
expensive. This changeset introduce a cache for this information. This cache is
hold by the repository (unfiltered repository) and invalidated when necessary.
This cache is not a protected attribute (leading _) because some logic that
invalidate it is not held by the local repo itself.
We add a `filtered` method on repo. This method return an instance of `repoview`
that behaves exactly as the original repository but with a filtered changelog
attribute. Filters are identified by a "name". Planned filter are `unserved`,
`hidden` and `mutable`. Filtering the repository in place what out of question
as it wont not allows multiple thread to share the same repo. It would makes
control of the filtering scope harder too. See the `repoview` docstring for
details.
A mechanism to compute filtered revision is also installed. Some caches will be
installed in later commit.
For a repository with over 400,000 commits, rebasing one revision near tip,
this avoids two treks up the DAG, speeding the operation up by around 1.6
seconds.
With the current implementation, `changelog.nodemap` is not filtered. So some
filtered changeset in common are not filtered by `n in nodemap`. This leads to
crash lower in the stack when the bundle generation try to access those node on
a filtered changelog.
The check pattern only checked for whitespace between keyword and operator.
Now it also warns:
> x = f(),7
missing whitespace after ,
> x = f()+7
missing whitespace in expression
All filecache usage on repo is for logic that should be unfiltered. The
caches should be common to all filtered instances, and computation must
be done unfiltered. A dedicated storecache subclass is created for
this purpose.
Some of the localrepo property caches must be computed unfiltered and
stored globally. Some others must see the filtered version and store data
relative to the current filtering.
This changeset introduces two classes `unfilteredpropertycache`
and `filteredpropertycache` for this purpose. A new function
`hasunfilteredcache` is introduced for unambiguous checking for cached
values on unfiltered repos.
A few tweaks are made to the property cache class to allow overriding
the way the computed value is stored on the object.
Some logic relative to _tagcaches is cleaned up in the process.
Computation of common changesets during push needs to be done on the
widest set possible. An unfiltered version of the repo is kept for
discovery and various revset calls. The discovery code itself enforces
the filtering of unserved outgoing changeset.
The current branchcache construction is not aware of filtering. We keep
the status quo, ensuring that the branch cache logic is computed as
before: without any filtering.
This decorator ensure the method in run on an unfiltered version of the
repository. See follow-up commit for details.
This decorator is not named `unfiltered` because it would clash with the
`unfilteredmethod` on `localrepo` itself.
This commit is part of the changelog level filtering effort. It returns
the main "unfiltered" version of a repo-like object. For localrepo this
means the same localrepo object. But this method will be overwritten
by the filtered versions of a repository to return the core unfiltered
version of the repo.
Introducing this simple method first allows later commits to prepare
for the use of a filtered version of a repository.
A new repo method is added because a lot of users may call it. At the
end of this series of commits, about 40 calls exist in core and hgext.
Bookmarks persistence still showed a fair amount of its legacy as a
monkeypatching extension. This encapsulates all bookmarks
serialization and parsing in a single class, and offers a single
location where other bookmarks storage engines can be substituted
in. As a result, many files no longer import the bookmarks module,
which strikes me as an encapsulation win.
This doesn't do anything to the current bookmark state yet, but I'm
hoping put that in the bmstore class as well.
This applies the same logic as used for `obsolete` and `unstable` changesets.
Refuse to push them without force.
We'll probably want to factor this logic with two new functions
`pctx.troubled()` and `ctx.troubles()`. But I'm waiting for the third
"trouble" to make it into core.
This factors out the checks from tags and bookmarks, and newly applies
the same prohibitions to branches. checknewlabel takes a new parameter,
kind, indicating the kind of label being checked.
Test coverage is added for all three types of labels.
Recomputing branch cache on clone may be expensive,
therefore if possible we fetch it along with the data.
- If the clone is performed by copying, we just copy branchcache file.
- If we localrepo.clone and streaming then we follow the procedure:
1. Fetch branchmap from the remote
2. Fetch the actual data.
3. Find the latest rev within branch heads (tip at the time of
branchmap fetch)
4. Update the cache for the revs in [remotetip+1, tip]
This way we ensure that the branchcache is correct even in case
of races with commits.
Tags initially prevented revision to be hidden. It seemed a bad idea to have
tags refer to revisions that one can't see. But proper filtering of hidden
revisions excludes them from tag computation. Coming changelog filtering will do
that. Anyway, tags that really matter will likely be public and therefore not
hidden.
The current working directory parent and bookmarked revision are still not
hidden. Bookmarks were likely automatically moved at rewrite time, bookmarks
that remain on obsolete revisions were probably moved there on purpose.
If there are filtered changesets the cache is not valid. We'll have to cache
branchmap for filtered state too, but for now recomputing the branchmap is
enough.
