[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