[MERGE] CHK maps (brisbane)
John Arbash Meinel
john at arbash-meinel.com
Fri Apr 3 03:55:06 BST 2009
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Ian Clatworthy wrote:
> This patch includes the new code and tests for CHK maps,
> one of the pillars of brisbane-core. As this is 99% new
> code, it has no impact on bzr.dev stability. It's also
> been reviewed by a mix of people (including me) and been
> heavily exercised for months now in the brisbane-core
> branch. I'm happy it is safe to land.
>
> The main thing to note is that, while all the tests are
> included, some of them need to be disabled until the
> development5 format loads. (It smells like a test layering
> violation than chk-map is tested via a repository format
> than depends on repo changes than depend on inventory changes
> than depend on chk-map but that's how it is.)
>
> Those higher layers are coming any hour/day now so this is
> just a temporary issue though. I *could* put all the layers
> together but that doesn't make sense from an ease of review
> perspective.
>
> Ian C.
>
We need a VersionedFile with the right index flags, and it was expedient
to create a Repository to provide it. I would think all of that code
could be easily rewritten to just change the "get_chk_bytes()" to build
its own VF and just return it.
...
+cdef extern from "zlib.h":
+ ctypedef unsigned long uLong
+ ctypedef unsigned int uInt
+ ctypedef unsigned char Bytef
+
+ uLong crc32(uLong crc, Bytef *buf, uInt len)
^- This may actually cause more headache than I originally expected. It
seems that Python statically compiles its own zlib implementation, and
doesn't expose any hooks into it... :(
Since I only need crc32, I would recommend just pulling that bit of code
into this file.
There are tons of IFDEF in the crc32.c code, that I think we can pretty
much just get rid of.
If it is going to delay anything, I suppose we can postpone. But it does
mean we start depending on having a separate 'z' library to compile against.
Another possibility is to just remove the optimized _search_key
functions. If we write the other code properly, they don't have to get
called all that often.
What do other's think?
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAknVeooACgkQJdeBCYSNAAMhdACfb2I19HuEHHl7FKr6lYRM45+Q
ur0AoLENJZ/Uunbf4FJeLeKhGarzV4np
=TFyI
-----END PGP SIGNATURE-----
More information about the bazaar
mailing list