I often find an update (or merge or perhaps other things) hangs
indefinitely at some point, when using Serf.
If I break (ctrl-C) and then repeat the update it carries on a similar
amount further. When I hit this problem with a merge I'm stuck because
merge doesn't like being re-started.
If I specify "http-library=neon" instead of serf, it doesn't hang and it
completes properly.
Repro script:
[[[
svn co --quiet https://svn.collab.net/repos/svn/branches/svnsync-obliterate@39389 wc
svn merge ^/trunk_at_38960 wc --config-option=servers:global:http-library=serf
svn --version
]]]
Output:
[[[
$ sh -x hang-test.sh
+ svn co --quiet https://svn.collab.net/repos/svn/branches/svnsync-obliterate@39389 wc
+ svn merge ^/trunk_at_38960 wc --config-option=servers:global:http-library=serf
--- Merging r38948 through r38960 into 'wc':
U wc/subversion/include/svn_wc.h
U wc/subversion/libsvn_wc/deprecated.c
U wc/subversion/libsvn_wc/lock.c
U wc/subversion/libsvn_wc/adm_crawler.c
U wc/subversion/libsvn_client/revisions.c
U wc/subversion/libsvn_client/patch.c
U wc/subversion/libsvn_client/checkout.c
U wc/subversion/tests/cmdline/export_tests.py
[### here it hung and I pressed ctrl-C]
/home/julianfoad/src/subversion-trunk2/subversion/svn/util.c:900: (apr_err=4)
/home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/merge.c:9283: (apr_err=4)
/home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/merge.c:7915: (apr_err=4)
/home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/merge.c:7596: (apr_err=4)
/home/julianfoad/src/subversion-trunk2/subversion/libsvn_client/merge.c:4685: (apr_err=4)
/home/julianfoad/src/subversion-trunk2/subversion/libsvn_ra_serf/update.c:2241: (apr_err=4)
svn: Error retrieving REPORT (4): Interrupted system call
+ svn --version
svn, version 1.7.0 (dev build)
compiled Sep 17 2009, 11:13:33
Copyright (C) 2009 The Subversion Corporation.
This software consists of contributions made by many people;
see the NOTICE file for more information.
Subversion is open source software, see http://subversion.tigris.org/
The following repository access (RA) modules are available:
* ra_neon : Module for accessing a repository via WebDAV protocol using Neon.
- handles 'http' scheme
- handles 'https' scheme
* ra_svn : Module for accessing a repository using the svn network protocol.
- with Cyrus SASL authentication
- handles 'svn' scheme
* ra_local : Module for accessing a repository on local disk.
- handles 'file' scheme
* ra_serf : Module for accessing a repository via WebDAV protocol using serf.
- handles 'http' scheme
- handles 'https' scheme
]]]
And here's what it looks like with Neon specified instead of Serf:
[[[
$ sh -x hang-test.sh
+ svn co --quiet https://svn.collab.net/repos/svn/branches/svnsync-obliterate@39389 wc
+ svn merge '^/trunk_at_38960' wc --config-option=servers:global:http-library=neon
--- Merging r38948 through r38960 into 'wc':
U wc/subversion/include/svn_wc.h
U wc/subversion/libsvn_wc/deprecated.c
U wc/subversion/libsvn_wc/lock.c
U wc/subversion/libsvn_wc/adm_crawler.c
U wc/subversion/libsvn_client/revisions.c
U wc/subversion/libsvn_client/patch.c
U wc/subversion/libsvn_client/checkout.c
U wc/subversion/tests/cmdline/export_tests.py
U wc/subversion/tests/cmdline/merge_tests.py
U wc/subversion/svnversion/main.c
U wc/build/win32
U wc/contrib/client-side/emacs/psvn.el
+ svn --version
svn, version 1.7.0 (dev build)
compiled Sep 17 2009, 11:13:33
[...]
]]]
svn is trunk_at_39389
neon is 0.26.1
serf is 0.3.0
The point at which it hangs is consistent for a given operation: for
example, every time I run that recipe it hangs after printing
"export_tests.py".
It feels to me like there is some data transfer size setting somewhere,
which makes it hang for me (and I've heard other reports), but not for
most people.
I've been seeing this effect for weeks but have only today investigated
and confirmed that it exists with serf and not neon, and with latest svn
build, and is somewhat reproducible.
Any ideas?
- Julian
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=462&dsMessageId=2396028
Received on 2009-09-17 16:45:23 CEST