revlog.group cached every chunk from the revlog, the behaviour was
needed to minimize the roundtrip with old-http.
We now cache the revlog data ~4MB at a time.
The memory used server side when pulling goes down to 35Mo maximum
whereas without the patch more than 160Mo was used when cloning the linux kernel
repository.
The time used by cloning is higher mainly because of the check in revlog.revision.
before
110.25user 20.90system 2:52.00elapsed 76%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+708707minor)pagefaults 0swaps
after
117.56user 18.86system 2:50.43elapsed 80%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+748366minor)pagefaults 0swaps
Make it actually work (undefined variable 'rev'; allow to pass a rev parameter).
repo.branchlookup() doesn't need a copy of heads because it doesn't modify it.
Use None as default argument to heads() instead of nullid.
Doc string PEPification.
and replaces it with calls to nodesbetween.
nodesbetween calculates all the changesets needed to have a complete
revision graph between a given set of base nodes and a given set of
head nodes.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fix out of range regression
From: Filip Brcic <brcha@users.sourceforge.net>
The old revlog.py issued "index out of range" error when cloning the repository
Now I have reverted the parts of revlog.py to the old state when prev was
initialized as -1 and later assigned self.tip() only if that is possible.
Previously prev was always initialized as self.tip() and that is where the
out of range error was.
manifest hash: c94c9aee8b6d382ef52c3981f306a6e7e5f4c4d1
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCzzIxywK+sNU5EO8RAtlcAJ0TX9FXuC2c3YHuYXNwqZhdzPWUlgCggq+a
yJzUKDKH/gvnD3Tx3jcmCn8=
=euPi
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fix corruption resulting from skipping parts of a revision group
We were occassionally losing track of what revision a delta applied to
when we skipped over deltas we already had and applying the delta
against the wrong base. This could result in coredumps from mpatch,
consistency errors, or failed verify.
manifest hash: fcf20a8abfd81f08fae2398136b2ed66216b2083
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCzu5SywK+sNU5EO8RAi10AJ9cqIfQzOzbcdH36t1LR/rY+UMtHwCeM79p
Dtv+Jh0McLZr6nf4iJyhDgI=
=5o6U
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Fix an odd revlog bug
If revlog had a cached -empty- revision, as opposed to no cached
version, it could get confused. This cropped up in verify on a
particular repo.
manifest hash: 90ccf122087f6bbcb4322cb9d9bb8124610ba886
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCzjRaywK+sNU5EO8RAgVEAKCv3WBJt1rBOX0UlTDXFPygPIru+gCfTZxJ
CEz1lYny1gkQ+haGY26QdBs=
=C/K5
-----END PGP SIGNATURE-----
# HG changeset patch
# User mason@suse.com
Performance enhancements for manifest.add()
Improve manifest.add performance by using bisect to insert/remove
changed items into the manifest list. This also generates the
manifest delta directly based on the changes being made.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ancestor algorithm fix
The ancestor algorithm was a bit too optimistic about node ordering
still. Add revision numbers to the comparison to sort things out.
manifest hash: f4eaf95057b5623e864359706dcaee820b10fd20
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCsTrCywK+sNU5EO8RAtqMAJ9fEJEesPn+0SMg/i/g5vZYmX/pBgCfVnhl
+s88q/Wilw27MVWP6J6oqX8=
=k9AU
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Change the size of the short hash representation
First note that this number doesn't really matter, as we always check
for ambiguous short hash ids.
Here's the math on collision probability:
>>> import math
>>> def p(f, n): return 1 - (1 / math.exp(n**2/(2*f)))
...
>>> p(2**32, 30000.0)
0.09947179164613551 # with 30000 changesets (BKCVS), we have a 9% chance
>>> p(2**32, 65000.0)
0.38850881217977273 # and with a full import from BK, we'd have a 39% chance
>>> p(2**40, 1e6)
0.36539171908447321 # we'd like to be "safe" for 1M csets, so 40 isn't enough
>>> p(2**48, 1e6)
0.001774780051374103 # But 48 looks good
>>> p(2**48, 1e7)
0.16275260939624481
>>> p(2**48, 5e6)
0.043437281083569146
>>> p(2**48, 2e6)
0.0070802434913129764
>>> p(2**48, 3e6)
0.01586009440574343
manifest hash: 24d9f928a463f46708b0e11fb781d5a241851424
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCsQoMywK+sNU5EO8RAoBBAJwII9GV6dT9QUOYAk3gZGw9z0JvjACfSI4q
IFnTu1F7P5OuLelO1GsM8Bs=
=CNWk
-----END PGP SIGNATURE-----
