0.6 release plan

[Martin Pool]

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.

> 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