0.6 release plan

John A Meinel john at arbash-meinel.com
Thu Oct 27 03:57:20 BST 2005


Martin Pool wrote:
> On 25/10/05, John Arbash Meinel <john at arbash-meinel.com> wrote:
> 
>>>> You might want to merge the rewritten revision XML and inventory XML,
>>>> though I wouldn't merge the very latest changes where I switched to
>>>> using python and xml.sax. (That would be merging up to bzr-sax 1450, not
>>>> up to 1451).
>>>
>>> OK, I'll look at that.
>> The main reason it needs to be done earlier rather than later, is that
>> it will once again break any sha hashes that we have.
>> I think we are going with "testaments" for signing, so it won't break
>> those. Other than <revision> references the sha1 hash of the <inventory>
>> and not it's testament.
>>
>> I don't know if you want to switch to a revision.weave, which I did not
>> implement (but would be pretty easy to do). The compression is
>> reasonable. With the latest bzr.dev tree which has 2367 total revisions,
>> I get an --apparent size of 1.2M, and a revisions.weave size of 1.1M.
> 
> I would like to do those things, or something like them, but let's put
> this release out first.

Whatever you would like. I would like to point out my other email, where
I went ahead and created an "upgrade" entry to a new branch format, and
that does include a revision weave. And optional compression for the
meta-data.

I also have thought more about my "compression" work. And I think it
could be done in the ".bzr/branch-format" rather than having a separate
file. That would save a round-trip when checking out an http branch.

But certainly you can do this type of change in an 0.7 release if you want.

John
=:->

> 
>> Also we might consider gzipping weave files. Because they have to be
>> rewritten completely each time. And that brings the size down to 336K.
>>
>> We might actually make it a branch property, whether the weave is
>> compressed or not. I'm just thinking that a published branch would be
>> nice to used compressed weaves, since most of the time is going to be
>> downloading time, but for a working branch, you might want uncompressed,
>> because you want the access time to be fast.
> 
>> Though in my testing, uncompressing an entire inventory.weave.gz only
>> takes 0.04s. Which is quite a bit less time than it takes to extract one
>> of it's entries.
> 
> OK. that's good to know.  I previously thought the Python gzip
> interface was very slow, but I think this is because the hotspot
> profiler tends to misattribute time used in generators.
> 
> --
> Martin
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051026/0bd94686/attachment.pgp 


More information about the bazaar mailing list