On Thu, Jul 18, 2013 at 3:10 PM, Anatoly Zapadinsky <zapadin...@gmail.com>wrote:
> On Thu, Jul 18, 2013 at 3:24 PM, Stefan Fuhrmann > <stefan.fuhrm...@wandisco.com> wrote: > > > > > > Have you tried it with any newer Windows version (post-W2k3)? > > There might be an address space fragmentation issue between > > CRT and OS memory management. > > Yes. I've tried it on Ubuntu 12.08 (1.8 subversion was compiled from > downloaded sources) and Windows XP Pro, at work... not with chromium > svn though. We have repository with some huge revisions in it, > although we have no problems dealing with it in normal everyday work > (checkout, log, blame, commit). I faced this trap trying to mirror it. > It is not an "address space fragmentation" because pages are committed > not just reserved, and it is very unlikely to be related to memory > manager at all because memory is deallocated after every successfully > downloaded revision. > Very good ... those issues are hard to work around. > Does the memory usage already build up while transmitting the > > data (i.e. while the dots are being shown) or mainly during the > > commit stage, i.e. the during short delay after the last dot and > > the "Committed revision xyz" message? > > On transmitting data stage. During the commit almost no additional > memory is allocated. > So, it depends on the number of changes in a revision and / or combined size of the changed nodes. Could you try running a local replication, i.e. from file:// to file:// or svn:// to file:// ? That way, we could rule out peculiarities of http and the serf lib. -- Stefan^2.