You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Julian Foad <ju...@btopenworld.com> on 2008/08/27 09:27:24 UTC
Re: svn.collab.net down? No.
On Wed, 2008-08-27 at 10:26 +0200, Jens Seidel wrote:
> I tried to update my source tree of subversion and the following
> happens:
>
> Subversion/1.5.x> svn up
>
> That's all.
svn.collab.net is not down.
Just seconds ago I ran
[[[
$ svn st -u
* 32719 subversion/tests/cmdline/svntest/tree.py
[...]
]]]
> I wait already multiple minutes and even Ctrl+C to interrupt it
> doesn't work. My network seems to work fine. It is a self compiled binary but I
> do not remember the revision number and it is no longer part of:
>
> $ svn --version
> svn, version 1.5.1 (dev build)
> compiled Jul 25 2008, 13:31:58
>
> Here is the backtrace of it using gdb:
> (gdb) bt
> #0 0x00002ad4347201bf in poll () from /lib64/libc.so.6
> #1 0x00002ad43401d913 in raw_poll (fdno=<value optimized out>, rdwr=<value optimized out>, secs=<value optimized out>)
> at ne_socket.c:390
> #2 0x00002ad43401da99 in timed_connect (sock=0x77e640, fd=3, sa=0x7fff799b1280, salen=<value optimized out>)
> at ne_socket.c:1023
> #3 0x00002ad43401dcc6 in ne_sock_connect (sock=0x77e640, addr=0x77e5f0, port=<value optimized out>) at ne_socket.c:1096
> #4 0x00002ad434017195 in send_request (req=0x7784e0, request=0x77b2a0) at ne_request.c:1489
> #5 0x00002ad4340182a6 in ne_begin_request (req=0x7784e0) at ne_request.c:1163
> #6 0x00002ad43401892d in ne_request_dispatch (req=0x7784e0) at ne_request.c:1372
> #7 0x00002ad432871ec9 in svn_ra_neon__request_dispatch (code_p=0x7fff799b1644, req=0x65d120, extra_headers=0x0,
> body=0x0, okay_1=200, okay_2=0, pool=0x658098) at subversion/libsvn_ra_neon/util.c:1422
> #8 0x00002ad43286d50e in exchange_capabilities (ras=0x772d78, pool=0x658098) at subversion/libsvn_ra_neon/session.c:793
> #9 0x00002ad43286e55d in svn_ra_neon__open (session=0x772cb0,
> repos_URL=0x658560 "http://svn.collab.net/repos/svn/branches/1.5.x", callbacks=0x772c30, callback_baton=0x772c80,
> config=0x642c60, pool=0x658098) at subversion/libsvn_ra_neon/session.c:1249
> #10 0x00002ad4317b60a3 in svn_ra_open3 (session_p=0x7fff799b1a50,
> repos_URL=0x658560 "http://svn.collab.net/repos/svn/branches/1.5.x",
> uuid=0x658640 "612f8ebc-c883-4be0-9ee0-a4e9ef946e3a", callbacks=0x772c30, callback_baton=0x772c80, config=0x642c60,
> pool=0x658098) at subversion/libsvn_ra/ra_loader.c:475
> #11 0x00002ad4313522e6 in svn_client__open_ra_session_internal (ra_session=0x7fff799b1a50,
> base_url=0x658560 "http://svn.collab.net/repos/svn/branches/1.5.x", base_dir=0x6583a8 "", base_access=0x658368,
> commit_items=0x0, use_admin=1, read_only_wc=1, ctx=0x642bc0, pool=0x658098) at subversion/libsvn_client/ra.c:324
> #12 0x00002ad431358757 in svn_client__update_internal (result_rev=0x7fff799b1bf0, path=0x656140 "",
> revision=0x7fff799b1e48, depth=svn_depth_unknown, depth_is_sticky=0, ignore_externals=0, allow_unver_obstructions=0,
> timestamp_sleep=0x7fff799b1bf8, send_copyfrom_args=1, ctx=0x642bc0, pool=0x658098)
> at subversion/libsvn_client/update.c:182
> #13 0x00002ad431358db3 in svn_client_update3 (result_revs=0x0, paths=0x6560f8, revision=0x7fff799b1e48,
> depth=svn_depth_unknown, depth_is_sticky=0, ignore_externals=0, allow_unver_obstructions=0, ctx=0x642bc0,
> pool=0x6421f8) at subversion/libsvn_client/update.c:319
> #14 0x000000000041909a in svn_cl__update (os=0x642430, baton=0x7fff799b1e20, pool=0x6421f8)
> at subversion/svn/update-cmd.c:83
> #15 0x00000000004112b4 in main (argc=2, argv=0x7fff799b2178) at subversion/svn/main.c:2018
>
> It is clearly not optimal to let the user wait forever and not to allow interrupting it.
> Is this a known problem, is the server just down, or what happend?
You're right that it's not optimal. What version of Neon are you using?
(I don't know the details but I think I recall that improvements in
cancellation support have been made over the years.)
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: svn.collab.net down? No.
Posted by Jens Seidel <je...@users.sourceforge.net>.
On Wed, Aug 27, 2008 at 10:27:24AM +0100, Julian Foad wrote:
> On Wed, 2008-08-27 at 10:26 +0200, Jens Seidel wrote:
> > I tried to update my source tree of subversion and the following
> > happens:
> >
> > Subversion/1.5.x> svn up
> >
> > That's all.
>
> svn.collab.net is not down.
Yep, some minutes later it worked for me as well. But svn failed at least
3 times for me.
What could be the reason? Maybe the server *was* down for a short time?
> > I wait already multiple minutes and even Ctrl+C to interrupt it
> > doesn't work. My network seems to work fine. It is a self compiled binary but I
> > do not remember the revision number and it is no longer part of:
> >
> > Here is the backtrace of it using gdb:
> > (gdb) bt
> > #0 0x00002ad4347201bf in poll () from /lib64/libc.so.6
> > #1 0x00002ad43401d913 in raw_poll (fdno=<value optimized out>, rdwr=<value optimized out>, secs=<value optimized out>)
> > at ne_socket.c:390
> > #2 0x00002ad43401da99 in timed_connect (sock=0x77e640, fd=3, sa=0x7fff799b1280, salen=<value optimized out>)
> > at ne_socket.c:1023
> > #3 0x00002ad43401dcc6 in ne_sock_connect (sock=0x77e640, addr=0x77e5f0, port=<value optimized out>) at ne_socket.c:1096
> > It is clearly not optimal to let the user wait forever and not to allow interrupting it.
> > Is this a known problem, is the server just down, or what happend?
>
> You're right that it's not optimal. What version of Neon are you using?
> (I don't know the details but I think I recall that improvements in
> cancellation support have been made over the years.)
A good question. I can no longer check the output of ldd svn as I tried
to update svn a few minutes ago (and failed). My system has the package
neon-0.26.1-26.1 installed (without -devel package). But I'm not sure
whether I linked against this. I think I remember it was too old so that
I installed a newer lib in my local tree. There I found a neon-config
script which outputs:
$ neon-config --version
neon 0.28.2
My local libneon.la refers nevertheless to libneon.so.27.1.2 (but the
timestamps of my local version match each other and are only two days
older than my old svn 1.5.1 binary). The source seems already be
deleted.
Maybe it's a case where I compiled against the header of a newer version
but used an older library from the system for linking. Nevertheless
that's the first time I was in trouble and my private copy of neon can
be found via $LD_LIBRARY_PATH.
Should I provide more diagnostics if it happens another time in future?
Jens
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org