it's very unlikely to be a memory leak... svnsync worked for 20+ hours and
synchronized 300 000+ revisions and downloaded 65+ Gb during the one sync
session before it felt in this trap. now it stuck... and can't synchronize
this revision after restart. The procedure is very slow, it took more than
an hour to sync this particular revision with 56000 files in it.
The cumulative files size in this revision is not very big, the size is
less than 4gb. Before it crashes transaction folder grows to 46mb in size
and txn-protorevs is 4Gb. Looks like it has already downloaded all the
files and crashed after it. Looks like it is a problem in handling huge
commit and not a memory leak, also may be the server terminated connection.
On Tue, Jul 9, 2013 at 9:13 PM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Tue, Jul 09, 2013 at 03:30:44PM +0400, Anatoly Zapadinsky wrote:
> > svnsync failed to sync repository with a single commit containing 56000
> > files. This commit handled perfectly by console svn and tortoise svn. We
> > can checkout this folder structure and so on. But when I tried to sync
> this
> > commit to the local mirror repository it fails.
> > 32 bit version of svnsync crashed with out of memory exception.
> > 64 bit version made a transaction folder containing 117000 files in it,
> > allocated like 3gb of memory and finally crashed with this diagnostic:
> > "svn: E235000: In file 'subversion/libsvn_ra_serf/util.c' line 1649:
> > internal malfunction".
> > May be this commit is not an example of the best practice but it crash
> only
> > svnsync all the other svn tools handle it perfectly.
> > What should I do? How to mirror this repository? Is it a bug or not?
>
> This problem sounds like a memory leak.
> I wonder if you're running into the same problem this user is seeing:
> http://svn.haxx.se/users/archive-2013-07/0128.shtml
>
Received on 2013-07-09 19:48:22 CEST