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.

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)
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...
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.
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).

fossil-users mailing list

Reply via email to