bzr-svn: The branch file:///c:/.../foo has no revision None

[Talden]

> It's a nasty thought, but wouldn't this potentially happen any time it
> repacks, and not just during upgrade? On a 32-bit OS the 2GB memory limit
> per process will be the restricting factor, and in the Windows world, 32-bit
> clients are still very much the norm especially in the corporate world -

It's even worse, even though you have half (2GB) of the 32bit (4GB)
address space you don't get to use all of it due to address-space
fragmentation.

DLLs load into their favoured base-address unless a collision occurs
and they are relocated.  This means that you end up with many tiny
blocks of free space and one or two large ones.

We've hit this with the Java VM for our application where the maximum
heap size is far below the available address space (and thanks to a
couple of Microsoft updates have found the maximum heap size to vary
from time to time).  Even though we may have 1.8GB free in the process
space the most we have 'reliably' been able to allocate is 1GB. I have
quotes around reliably because we have recently hit one machine with
some administration software installed that injects a DLL into every
process and that likes to sit right-the-f*ck (hereby referred to as
RTF because I like TLAs) in the middle of the address-space.

I assume python does something similar as the process exited with a
memory error at ~1.2GB.

> I've only just had a couple of my servers upgraded to 64-bit OSs (to run
> some fairly whopping Java processes). A process that needs > 2GB of RAM to
> complete is OK when you have a 64-bit server to run it on, but the nature of
> DVCS works against it here - 32-bit workstations won't be able to perform
> the same packing job (if it requires this much memory each time).

As I understand it, in 64bit Microsoft hasn't fixed this fragmentation
issue at all, you just have such a massive address space that it
shouldn't be an issue in any normal circumstance.

Hopefully it's practical to adjust the packing algorithm so that it
doesn't need so much memory.

--
Talden