Uses a transaction instance from the local repository to journal the
truncation of revlog files, such that if a strip only partially completes,
hg recover will be able to finish the truncate of all the files.
The potential unbundling of changes that have been backed up to be restored
later will, in case of an error, have to be unbundled manually. The
difference is that it will be possible to recover the repository state so
the unbundle can actually succeed.
Because we often compute sha1(nullid), it's interesting to copy a precomputed
hash of nullid instead of computing everytime the same hash. Similarly, when
one of the parents is null, we can avoid a < comparison (sort).
Overall, this change adds a string equality comparison on each hash() call,
but when p2 is null, we drop one string < comparison, and copy a hash instead
of computing it. Since it is common to have revisions with only one parent,
this change makes hash() 25% faster when cloning a big repository.
They are unnecessary. I did leave them in localrepo.py where there is
something like:
_junk = foo()
_junk = None
to free memory early. I don't know if just `foo()` will free the return
value as early.
- create error.py for exception classes to reduce demandloading
- move revlog exceptions to it
- change users to import error and drop revlog import if possible
changegroup() has a problem when nodes which does not descend from a node
in <bases> are added to remote after the discovery phase.
If that happens, changegroup() won't send the correct set of nodes, ie.
some nodes will be missing.
To correct it we have to find the set of nodes that both remote and self
have (called <common>), and send all the nodes not in <common>.
This fix has some overhead, in the worst case it will re-send a whole branch.
A proper fix to avoid this overhead might be to change the protocol so that
the <common> nodes are sent (instead of the <bases> of the missing nodes).
Previously, an unknown node id would lead to the following error:
abort: 00changelog.i@343445453433: no node!
All other unknown revision would instead display as:
abort: unknown revision '343445453'!
The former error message has been suppressed in favor of the latter.
This patch adds two methods to revlog:
- ancestors: given a list of revisions returns their ancestors
- descendants: given a list of revisions return their descendants
If there's no inline data, revlog.revision opens the data file every
time it's called. This is useful if we're going to call chunk many
times, but, if we're going to call it only once, it's better to let
chunk open the file - if we're lucky, all the data we're going to need
is already cached and we won't need to even look at the file.
When we remove revision N from the repository, all revisions >= N are
affected: either it's a descendant from N and will also be removed, or
it's not a descendant of N and will be renumbered.
As a consequence, we have to (at least temporarily) remove all filelog
and manifest revisions that have a linkrev >= N, readding some of them
later.
Unfortunately, it's possible to have a revlog with two revisions
r1 and r2 such that r1 < r2, but linkrev(r1) > linkrev(r2). If we try
to strip revision linkrev(r1) from the repository, we'll also lose
revision r2 when we truncate this revlog.
We already use changegroupsubset to create a temporary changegroup
containing the revisions that have to be restored, but that function is
unable to detect that we also wanted to save the r2 in the case above.
So we manually calculate these extra nodes and pass it to changegroupsubset.
This should fix issue764.
