Please build the from the tip of the forum-v2 branch and let me know whether or not it is working for you.
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 > -- D. Richard Hipp d...@sqlite.org _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
