(bringing this to dev)
Anatoly sent me some more info in this issue and log files of svnsync
1.8.0+serf 1.2.1 with logging enabled.
He's running svnsync from a https repository (ra_serf) to a local
repository (ra_local). This on an Ubuntu 12.08 VM with 64-bit binary.
In the log files I received doesn't abort but stops with this error
(after hours of syncing):
r:10.14.3.25:443] outgoing.c: cleanup - closed socket, status 9
svnsync: E000005: Can't open file
... (cleanup and end program)
As far as I can see in the logs in this particular run there's nothing
wrong on the receiving end in ra_serf, but there's a problem during
the commit action.
I suppose (to be confirmed) that his target repository is stored on an
nfs or smb share.
Svn has a retry feature in fsfs to retry opening files after receiving
an EIO error, see libsvn_fs_fs/fs_fs.c RECOVERABLE_RETRY_COUNT, but I
don't see this being used in read_next_ids (fs_fs.c) when opening the
Can anyone more knowledgeable about fsfs confirm that this is a
possible explanation for this issue?
On Tue, Jul 9, 2013 at 1:30 PM, Anatoly Zapadinsky <zapadinsky_at_gmail.com> 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
> 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?
Received on 2013-07-17 13:50:43 CEST