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

[Adrian Wilkins]

> I'm trying this sequence again with 1.17 so I'll let you know if the
> problem vanishes.  If I fail the repack again I'll rerun with
> performance monitors and see where process memory gets to at the point
> it aborts - I note from event logs that virtual memory was not
> exhausted so I expect the process address space was exhausted.
> 
> I'm aware this repacking memory issue probably isn't a bzr-svn problem
> as much as an indication of problems repacking a largish 2a repo in
> Win32.  However I mention it here (and to you Jelmer specifically) as
> I suspect other Win32 users of svn-import with medium to large repos
> might hit it so you might want to watch out for it.

I ran into this trying to convert our bzr-svn repo to --2a ; when it was 
repacking mine it just dropped dead though. This was a while back when 
--2a first materialized and I've not tried since. I've seen at least one 
NEWS item stating that --2a uses a lot less memory under certain 
circumstances now.

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 - 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).

I'll have another crack with 1.17 when I have the time though.