On Thu, Jul 18, 2013 at 3:10 PM, Anatoly Zapadinsky <zapadinsky_at_gmail.com>wrote:
> On Thu, Jul 18, 2013 at 3:24 PM, Stefan Fuhrmann
> <stefan.fuhrmann_at_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.
Received on 2013-07-18 15:43:52 CEST