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