bzr-svn: The branch file:///c:/.../foo has no revision None
adrian.wilkins at gmail.com
Thu Jul 23 15:22:24 BST 2009
> 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
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.
More information about the bazaar