when doing something surprising, say so

[Michael B. Trausch]

On Tue, 4 Aug 2009, Martin Pool wrote:
> In the case of 407834 it's not unexpected that doing on-the-fly
> translation of formats would be more work than just copying across the
> compressed records, but it may be unobvious to the user that this is
> occurring.  So I'd say we should give a warning here.  In general if
> we're falling back to a more generic or unoptimized code path we
> should warn.

Just my two cents, being the reporter of 407834:  "Slow" is an 
understatement.  I branched in 30 minutes normally.  Even _locally_, 
though, I never managed to finish the conversion to 2a before I was put 
back in a forced-reboot situation (I have a _royally_ buggy graphics 
chipset)...

I can see converting something from one format to another (locally) taking 
maybe ten times the time it takes to branch it in its native format, 
though admittedly I don't really know just how much work is involved in 
the conversion.  I can only observe that it appears to be mostly CPU-bound 
(and only using a single of my cores).

I'm not sure if that's by necessity of design or if the excessive slowness 
is a fact-of-life migrating a large repo from a non-2a format to 2a.  If 
the latter, though, bzr should probably be able to look at a repository 
and maybe give a (very rough, erring on the side of longer) estimate of 
conversion.  I can try to, say, convert the MySQL repository on several 
systems with varying amounts of CPU, chip-RAM, and VM repeatedly to try to 
provide data that might be useful for such a thing, if that would be 
desired.

Well, on three systems: an older 2 GHz P4 with 512 MB chip memory, a dual 
2.2 GHz x86-64 with 1.5 GB chip memory, and a quad-core with 6 GB chip 
memory.  I might have a sub-1 GHz that I can use for the task with limited 
RAM as well.  The only problem with the quad core is that if the video 
borks during the test, I'll have to wait until it's finished to work on 
anything else.  :-P

 	--- Mike