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-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
lazyparser speed ups
When we do __contains__ on a map, we might as well load the whole
index. Not doing this was slowing down finding new changesets quite by
a factor of 20. When we do a full load, we also attempt to replace the
revlog's index and nodemap with normal Python objects to avoid the
lazymap overhead.
manifest hash: 9b2b20aacc508f9027d115426c63a381d28e5485
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCreYIywK+sNU5EO8RAoNHAJ9+LmXqsTQb9Bh3mZHq0A0VfQOleQCffHmn
jC/O0vnfx5FCRsX2bUFG794=
=BDTz
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
revlog: allow duplicates
If two branches make the same change to the same parent, the result
will be an identical hash. Git apparently does this all the time. Deal
with it gracefully.
manifest hash: c6217eab4b310e1ae529dd75ab90e717dbe5d55d
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCqU61ywK+sNU5EO8RAkFqAJ9KhWUQgjZbzzB/+mTkolH0GkT1awCfa+Mj
ulbI4xCRZcvfQE492mcNwQA=
=N6In
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
fix bad assumption about uniqueness of file versions
Mercurial had assumed that a given file hash could show up in only one
changeset, and thus that the mapping from file revision to changeset
was 1-to-1. But if two people perform the same edit with the same
parents, we can get an identical hash in different changesets.
So we've got to loosen up our uniqueness checks in addgroup and in
verify.
manifest hash: 5462003241e7d071ffa1741b87a59f646c9988ed
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (GNU/Linux)
iD8DBQFCoMDkywK+sNU5EO8RAg9PAJ9YWSknfFBoeYve/+Z5DDGGvytDkwCgoMwj
kT01PcjNzGPr1/Oe5WRvulE=
=HC4t
-----END PGP SIGNATURE-----
