On 07.08.18 15:53 , Richard Hipp wrote:
Please build the from the tip of the forum-v2 branch and let me know
whether or not it is working for you.

if the server machine is running that version, yes it does indeed. thanks a lot for looking into this issue ...

I see from the checkin message that the "fix" is achieved by "Disable the backoffice for SSH client". whatever the actual interaction between backoffice and ssh client: why did I see the problem only when actually cloning from another machine, whereas a clone using ssh while being loggedin to the server machine still worked? in both cases the ssh communication should be the same, no?

On 8/7/18, joerg van den hoff <veedeeh...@gmail.com> wrote:

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