[RFC][DRAFT] Updated guide for upgrading to rich-roots [and the 2.0 beta formats]

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


So what I see is:

$ du -ksh qbzr-*/.bzr
4.6M    qbzr-trunk/.bzr
7.5M    qbzr-2a/.bzr
1.7M    qbzr-2a-packed/.bzr

...

So just upgrading without packing causes it to expand a little bit,
packing makes it get much smaller again.

Note there are only 6 pack files at this point. And 4 of them are 1.5MB.
(Interesting that the one containing the packed versions of the first 1k
revs is actually smaller than the next one containing just 100 revs...)

My guess is that as development as increased you've gotten more stuff
changing, but even further, you've been doing .po work, which probably
has a lot of churn. (I'm guessing on that, though.)

> 
> BTW, 1.9-rich-root format is also slower than plain 1.9 here:
> 
> C:\Temp\qbzr-bbc>timeit bzr get trunk-1.9 test
> Branched 769 revision(s).
> 
> time: 6.242
> 
> C:\Temp\qbzr-bbc>timeit bzr get trunk-2a test
> Branched 769 revision(s).
> 
> time: 9.352
> 
> C:\Temp\qbzr-bbc>timeit bzr get trunk-1.9rr test
> Branched 769 revision(s).
> 
> time: 7.302
> 
> Last numbers is for 1.9-rich-roots.
> 
> 2Vincent: probably this is another reason why I don't upgrade my
> branches to rich-roots? Because rr is a bit slower?

There are more nodes in the per-file graph, because now we track when
the "root" changes. And a while ago, it was determined that upgrading
from non-rich to rich should add a node at *every* revision. I've
re-raised the discussion, and people felt that probably was indeed
silly, but not enough to actually go write the code to change the
upgrade process.

As for the main issue with this:

>>> len(qbzr_trunk.repository.texts.keys())
2717
>>> len(qbzr_rr.repository.texts.keys())
4172

So about 1.5:1 the number of 'texts' we have to transfer now.	

time bzr branch qbzr/trunk test --no-tree
2.122s

time bzr branch qbzr-2a/trunk test --no-tree
5.000s

time bzr branch qbzr-2a-packed/trunk test --no-tree
2.637s

I have a possible patch which drops the 2.6s down to ~2.3s by changing
how we parse the entry lines to extract the (file_id, revision_id) keys.
However, I'm still poking at it a bit. Note that my "qbzr/trunk" branch
has a single pack file (since that is what 'bzr branch' creates...)

John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAko2umoACgkQJdeBCYSNAANVmQCeP1CuZynekEe9lnnmBi7o9Nir
qsYAoL3Nan2thOo/bOCNa81rjDx94t7C
=5uWl
-----END PGP SIGNATURE-----