On 07.08.18 00:36, Richard Hipp wrote:
> On 8/6/18, joerg van den hoff <veedeeh...@gmail.com> wrote:
>> question: the observation that it seemingly is related specifically to
>> repos holding uv files is unimportant/irrelevant? or does that have
>> implications where to look?
>
> This is not much help in debugging. But it is helpful to you in
> bisecting, because it allows you to quickly and easily determine if a
> particular various is working or not.
>
> BTW, when doing the bisect, be sure to use the same Fossil version on
> both ends of the SSH connection. We do not know on which end the
> problem exists, so it is better to eliminate that variable.
>
>> then I do wish you much success with achieving that, of course.
>
> Your assistance in bisecting the delay problem is a step in that
> direction. Thanks.
this is what I've got:
bisect complete
1 BAD 2018-07-31 23:38:39 71260ba25e79f4aa
# error message, clone fails
5 BAD 2018-07-24 22:01:12 42d821a714d092a8
# error message, clone fails
7 BAD 2018-07-19 18:54:39 ac6657e2d35c974d
# clone hangs infinitely, no error message
9 BAD 2018-07-19 17:22:04 ada7ecde5bf91e18
# clone hangs infinitely, no error message
10 BAD 2018-07-19 16:27:51 f525b6d5e9dcb775
# clone hangs infinitely, no error message
11 BAD 2018-07-19 15:58:36 a32a92d227be5663 CURRENT
# clone hangs infinitely, no error message
8 GOOD 2018-07-19 15:52:43 aa17077eafbbad37
6 GOOD 2018-07-18 19:22:31 752ea432d1cf20fa
4 GOOD 2018-07-14 20:11:37 023ce4edde8ceb2d
3 GOOD 2018-06-23 15:48:49 aeb98be80f1d51f5
2 GOOD 2018-01-07 21:38:26 5b558bc76bb9fb5f
so the last good one is aa17077eafbbad37.
NOTE:
1.
I ran this with another repo not holding any uv files and still got the
errors. so my previous observation (only affecting uv sync seems
spurious or at least not true for all repos)
2.
the bisect is true for the scenario: use ssh-transport from a local
machine over the wire to the remote server. it does *not* happen (with
this repo) if I do the same while being logged in to the server holding
the remote repo. in the latter case the clone suceeds with tip of trunk...
3.
I have added comments in the bisect log which refer to the checkin
_above_ the comment. the point I want to stress is that the BAD
behaviour changes during the bisect: initially after the last GOOD
checkin, the clone just hangs and never comes back, later/more recently
the error messages and manifest "clone aborted/failed" messages appear.
4.
the bisect was performed on the (linux/ubuntu) server while keeping
the local (osx) labtop version of fossil constant (on 71260ba25e79f4aa,
I believe). so I think this proves that the problem is happening "on the
other side", not locally).
hth,
joerg
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
