On 11/29/06, Marinus Damm <marinus@jivesoftware.com> wrote:
>
> Trying to go from a svn 1.4.2 source to a 1.3.2 destination.
>
> a. Created a new empty 1.4.2 source repository, svnadmin load'ed a 3.9GB
> dump file into it.
> b. Created a new empty 1.3.2 destination repository on another host.
> c. svnsync init https://dest.example.com/svn2/repos
> file:///local/svn/repos <-- works fine
> d. svnsync sync https://dest.example.com/svn2/repos <--
> fails after several hours
>
> The sync gets to around rev 15000 and then dies; command line error message
> is:
>
> ...
> Copied properties for revision 15540.
> Committed revision 15541.
> Copied properties for revision 15541.
> svnsync: OPTIONS request failed on '/svn2/repos'
> svnsync: OPTIONS of '/svn2/repos': SSL negotiation failed: Cannot allocate
> memory (https://dest.example.com)
As far as I can see, that's a client side error, meaning that this is
a problem with Neon not being able to allocate more memory, or openssl
(against which neon is linked for SSL support).
Maybe Neon or svnsync forgets to deallocate some resource? It would be
great if you or someone else could try to find out. (How? Using
valgrind or pool-debugging?)
> Both O.S.'s are CentOS 4 (clone of RedHat Enterprise Linux 4).
> Subversion was built on the local machine in both cases.
> I'm not sure where to begin looking for the problem; is the error message
> passed out of svnsync from the destination machine? Or is svnsync (and neon
> I guess) on the source machine complaining?
It's the machine on which svnsync is running.
> Any suggestions to relieve the condition? This will be a one-time sync as
> part of our mirroring setup, so subsequent svnsync's should be much smaller
> than this initial one. The sync is roughly 40% done (both in terms of rev#s
> and size) when it dies.
I think it's safe to restart from where it left off. Does that work?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Nov 29 18:27:56 2006