[fossil-users] 'fossil open' and existing local 'manifest' and 'manifest.uuid' files

[Artur Shepilko]

By chance, just stumbled upon a curious issue: When executing 'fossil
open' for a newly created repo, if there're any existing local files
named "manifest" and "manifest.uuid"  these get deleted.
---
$ mkdir x
$ cd x
$ ls

$ fossil new ../x.fossil
$ touch manifest manifest.uuid
$ ls
manifest  manifest.uuid

$ fossil open ../x.fossil
project-name: 
repository:   /home/developer/test/../x.fossil
local-root:   /home/developer/test/x/
config-db:/home/developer/.fossil
project-code: 675a3d32b3ea9a69b6e96449c4394589ff084c7a
checkout: fa1ef0afb6f8c4c3533b9508684527ca5603e2ca 2018-08-08 02:29:41 UTC
tags: trunk
comment:  initial empty check-in (user: developer)
check-ins:1

$ ls
---

This is applicable to both Linux and Windows.

Is this by design or that's a bug?
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Who runs Fossil servers on Windows?

[Eugene Mindrov]

Richard,

I'm running fossil as a server on my Windows laptop using approach #1:

fossil.exe  server --localhost --port 80

> If you are running a Fossil server on Windows, please share with me
> how you set it up. You can respond via private email directly to me
> if you like.
> 
> (1) Run using "fossil server"
> (2) Run using "fossil winsrv"
> (3) Using Apache with CGI
> (4) Using Apache with SCGI
> (5) Using Nginx with SCGI
> (6) Via SSH using some kind of SSHD for Windows
> (7) Some other webserver (please specify)
> (8) Other (please specify)
> 
> I have the impression that most if not all Fossil servers on Windows
> are run using either (1) or (2). If you are using any of the other
> approaches, then I especially want to hear from you.
> 
> Thanks.
> 
> --
> 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Who runs Fossil servers on Windows?

[The Tick]

On 8/7/2018 11:55 AM, Richard Hipp wrote:

If you are running a Fossil server on Windows, please share with me
how you set it up.  You can respond via private email directly to me
if you like.

  (1)  Run using "fossil server"
  (2)  Run using "fossil winsrv"
  (3)  Using Apache with CGI
  (4)  Using Apache with SCGI
  (5)  Using Nginx with SCGI
  (6)  Via SSH using some kind of SSHD for Windows
  (7)  Some other webserver (please specify)
  (8)  Other (please specify)

I have the impression that most if not all Fossil servers on Windows
are run using either (1) or (2).  If you are using any of the other
approaches, then I especially want to hear from you.

Thanks.



I played with fossil under windows and, as far as I know, got it to 
work. I used the Abyss Web Server. At one time I set up port forwarding 
on my router for another little project and friends were able to connect 
successfully although they did not access the fossil stuff.


A link in a web page:
Tcl CWind extension

cgi-bin/fossil:
#!C:/bin/fossil.exe
directory: C:/Progra~1/AbyssW~1/htdocs/FossilRepositories
notfound: /badfossil.php

.../htdocs/Fossil/Repositories contains hardlinks to the actual fossil 
repositories:
htdocs/Fossil/Repositories/CWind.fossil  
C:/Users//Downloads/MyTclStuff/CWind.fossil


badfossil.php:

  
Fossil Repository Not Found
  
  
Fossil Repository Not Found

  





I asked some time ago if there was a way to pass more specific 
information to the "badfossil.php" page but, since I got no response, I 
assume the answer is "no".


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[Andy Bradford]

Thus said Richard Hipp on Tue, 07 Aug 2018 11:02:03 -0400:

> That would delay the second HTTP request coming over the SSH connection.

When I suggested  that, I didn't understand enough  about the backoffice
design---specifically that it was a long-running task. After reading the
forum page  you sent, I  see that  what you're looking  for is a  way to
fork() off a backend  process and only have one of  those operating at a
given time.

Andy
-- 
TAI64 timestamp: 40005b69ea80


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Who runs Fossil servers on Windows?

[Artur Shepilko]

>   (1)  Run using "fossil server"

Actually, it runs local to the PC, mainly to [self-]serve Wiki.

Now looking at 'fossil help winsrv' it seems that this would be a
better fit for such a use... Thanks :)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why no EXE+DLL like SQLite?

[Gilles]

On 07/08/2018 20:12, Stephan Beal wrote:
That time frame is familiar to me, so i had to check... a couple 
timeline entries mention his use of libfossil, and late 2014 was when 
chronic RSI knocked me out of my hobby projects (which included 
libfossil).

Too bad no one read, willing and able took over its development.

http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/wiki/home
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why no EXE+DLL like SQLite?

[Stephan Beal]

On Tue, Aug 7, 2018 at 4:15 PM Donald Griggs  wrote:

> Re:  http://www.tortoisefossil.org/index.cgi/index  "What you'll find
> here is a work in progress  "
>
> Unfortunately, it appears the project is at least on hiatus, if not
> abandoned.  The last code commit in the timeline was in late 2014.
>

That time frame is familiar to me, so i had to check... a couple timeline
entries mention his use of libfossil, and late 2014 was when chronic RSI
knocked me out of my hobby projects (which included libfossil).

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Error during commit

[Artur Shepilko]

> My guess is that you are probably overflowing a 32-bit integer
> someplace.  If so, I fear that this will not be something easily
> fixed.
>

Looks like it's the case at least in one place.
There's int64 => unsigned int overflow at the call to blob_resize()
(blob.c:865 
[http://fossil-scm.org/index.html/artifact?udc=1=on=b3ef46413b7313ca]
).

Generally this is tied to the way the Blob type is defined, so the fix
indeed may be painful and involve thorough testing.
This only becomes an issue with LARGE file sizes that overflow the
(unsigned int), which as DRH mentioned is somewhat beyond the expected
Fossil use-cases.

From the code I don't see any easy workaround other than addressing
the sizes of the files stored at the client's end.

May be trying to build a 64-bit version of the Fossil and explicitly
force the int to 64-bit size
BUT this may blow in some other place, so I would not trust it even if
it worked.

I also wonder at effectiveness of tracking the binaries, as these
won't diff properly, thus each new version would likely be stored
entirely, which would kinda turns repo into a gigantic zip archive
with a lot of overhead. I'd rather keep track of a __reference__ to
such binaries, while the binaries could be stored at some other bulk
storage location. Thus a project version would fetch an updated
reference and the pull the resp. binary.


---
src/vfile.c:820
[http://fossil-scm.org/index.html/artifact?udc=1=on=8c891c745e280c02]

rc = blob_read_from_file(, zFullpath, RepoFILE);

---
src/blob.c:843 
[http://fossil-scm.org/index.html/artifact?udc=1=on=b3ef46413b7313ca]

sqlite3_int64 blob_read_from_file(
  Blob *pBlob,   /* The blob to be initialized */
  const char *zFilename, /* Extract content from this file */
  int eFType /* ExtFILE or RepoFILE - see above */
){
  sqlite3_int64 size, got;
...

  size = file_size(zFilename, eFType);
...
  blob_resize(pBlob, size);

---
src/blob.c:442 
[http://fossil-scm.org/index.html/artifact?udc=1=on=b3ef46413b7313ca]

void blob_resize(Blob *pBlob, unsigned int newSize){
  pBlob->xRealloc(pBlob, newSize+1);
   pBlob->nUsed = newSize;
   pBlob->aData[newSize] = 0;
}
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] `set uv-syn on' only partly honoured (again)

[joerg van den hoff]

with current tip of trunk

fossil set uv-sync on

is not honoured by `clone', i.e. without explicit `clone -u', the uv files are not cloned. a 
subsequent `sync' (w/o the `-u'), however, does indeed initiate transfer of the uv-files from remote 
repo into the new clone. according to manpage the same should happen with `clone' if uv-sync is "on".

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Who runs Fossil servers on Windows?

[Richard Hipp]

If you are running a Fossil server on Windows, please share with me
how you set it up.  You can respond via private email directly to me
if you like.

  (1)  Run using "fossil server"
  (2)  Run using "fossil winsrv"
  (3)  Using Apache with CGI
  (4)  Using Apache with SCGI
  (5)  Using Nginx with SCGI
  (6)  Via SSH using some kind of SSHD for Windows
  (7)  Some other webserver (please specify)
  (8)  Other (please specify)

I have the impression that most if not all Fossil servers on Windows
are run using either (1) or (2).  If you are using any of the other
approaches, then I especially want to hear from you.

Thanks.

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

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[Andy Bradford]

Thus said Richard Hipp on Tue, 07 Aug 2018 10:21:34 -0400:

> yes, we do want backoffice to run for SSH transport.

Then I suggest that we simply make backoffice_run() smart enough to know
that it has already run once:

For example,  perhaps instead of  a panic here,  backoffice_run() should
just return?

http://www.fossil-scm.org/index.html/artifact?udc=1=225-227=d2cf5ceb442267a8

Thanks,

Andy
-- 
TAI64 timestamp: 40005b69ae87


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[joerg van den hoff]

On 07.08.18 16:16 , Andy Bradford wrote:
> Thus said joerg van den hoff on Tue, 07 Aug 2018 16:10:15 +0200:
>
>> 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?
>
> How  were you  cloning  while  logged in  to  the  server machine?  What
> commands did you use while loggged in to the server to clone?

uups, you are right, sorry for me spreading "misinformation":

actually the clone while being logged in to the server (via ssh ... ;)) was 
done via file system
transport, _not_ via ssh transport (I simply used `fossil clone 
/path/to/repo.fossil ...'). that of
course explains it, I presume...

again, sorry for the noise,

joerg

>
> Thanks,
>
> Andy
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why no EXE+DLL like SQLite?

[Gilles]

On 07/08/2018 16:14, Donald Griggs wrote:
Re: http://www.tortoisefossil.org/index.cgi/index     "What you'll 
find here is a work in progress  "


Unfortunately, it appears the project is at least on hiatus, if not 
abandoned.  The last code commit in the timeline was in late 2014.

It's a known pattern.

https://fuel-scm.org/fossil/index
2015/08/23 Fuel version 1.0.1 has been released

http://code.google.com/p/jurassic-fossil/
Latest commit 5b8862e  on Jul 21, 2011

http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil
"The requested URL /cgi-bin/ikoch/sharpfossil was not found on this server."

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[Richard Hipp]

On 8/7/18, Andy Bradford  wrote:
> Does it  make sense to  have backoffice_run()  in the SSH  transport? If
> not, then your fix is apropos.

yes, we do want backoffice to run for SSH transport.  My "fix" is
really a work-around, not a true fix.  We need to devise a proper fix
for this, but I don't yet have a vision of how to do that.  I'm in the
process of writing a long post of the "forumtest1" site now that tries
to discuss the problems and asks for ideas for a solution.  I'll send
follow-up email to this list when that post is up.
-- 
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

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[Andy Bradford]

Thus said joerg van den hoff on Tue, 07 Aug 2018 16:10:15 +0200:

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

How  were you  cloning  while  logged in  to  the  server machine?  What
commands did you use while loggged in to the server to clone?

Thanks,

Andy
-- 
TAI64 timestamp: 40005b69a9d2


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why no EXE+DLL like SQLite?

[Donald Griggs]

Re:  http://www.tortoisefossil.org/index.cgi/index  "What you'll find
here is a work in progress  "

Unfortunately, it appears the project is at least on hiatus, if not
abandoned.  The last code commit in the timeline was in late 2014.


>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[joerg van den hoff]

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  wrote:



On 07.08.18 00:36, Richard Hipp wrote:
  > On 8/6/18, joerg van den hoff  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 GOOD2018-07-19 15:52:43 aa17077eafbbad37
6 GOOD2018-07-18 19:22:31 752ea432d1cf20fa
4 GOOD2018-07-14 20:11:37 023ce4edde8ceb2d
3 GOOD2018-06-23 15:48:49 aeb98be80f1d51f5
2 GOOD2018-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

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[Andy Bradford]

Thus said Richard Hipp on Tue, 07 Aug 2018 09:53:35 -0400:

> Please build the from  the tip of the forum-v2 branch  and let me know
> whether or not it is working for you.

I was just about to submit a similar fix but you beat me to it.

The  reason  why this  doesn't  work  the  same  as a  traditional  HTTP
connection is because the SSH transport uses a single connection for all
communications,  whereas  the HTTP  transport  uses  one connection  per
request.

If we want to continue to  have backoffice_run() work with an SSH client
we would  need a  counter to  keep track of  how many  times a  sync has
happened (there may already be one available but I would have to look at
the code).

Does it  make sense to  have backoffice_run()  in the SSH  transport? If
not, then your fix is apropos.

Thanks,

Andy
-- 
TAI64 timestamp: 40005b69a76f


___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why no EXE+DLL like SQLite?

[Gilles]

Does it work?

"What you'll find here is a work in progress to have a Tortoise-style 
tool for Fossil repositories. Currently there is no release just yet, 
there are no commands implemented as of right now, but file overlays are 
working great."

http://www.tortoisefossil.org/index.cgi/index

On 07/08/2018 15:54, sky5w...@gmail.com wrote:

Hmmm, that sounds like TortoiseFossil?
I would deploy that if available. :)

On Mon, Aug 6, 2018 at 9:42 PM, Gilles > wrote:


On 07/08/2018 03:21, Ron W wrote:

I never tried Sharp Fossil, but Fuel was a very clunky GUI. I
think non-programmers would be unwilling to put up with it.

As a simpler alternative, the "GUI" could just be implemented as
an extension to Windows Explorer, where users would just
right-click a folder to perform the main tasks provided by Fossil
(commit, gdiff, etc.)

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org

http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users





___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Why no EXE+DLL like SQLite?

[sky5walk]

Hmmm, that sounds like TortoiseFossil?
I would deploy that if available. :)

On Mon, Aug 6, 2018 at 9:42 PM, Gilles  wrote:

> On 07/08/2018 03:21, Ron W wrote:
>
> I never tried Sharp Fossil, but Fuel was a very clunky GUI. I think
> non-programmers would be unwilling to put up with it.
>
> As a simpler alternative, the "GUI" could just be implemented as an
> extension to Windows Explorer, where users would just right-click a folder
> to perform the main tasks provided by Fossil (commit, gdiff, etc.)
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[Richard Hipp]

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  wrote:
>
>
> On 07.08.18 00:36, Richard Hipp wrote:
>  > On 8/6/18, joerg van den hoff  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 GOOD2018-07-19 15:52:43 aa17077eafbbad37
>6 GOOD2018-07-18 19:22:31 752ea432d1cf20fa
>4 GOOD2018-07-14 20:11:37 023ce4edde8ceb2d
>3 GOOD2018-06-23 15:48:49 aeb98be80f1d51f5
>2 GOOD2018-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

Re: [fossil-users] The backoffice. Was: strange delay and messages during `fossil (uv) sync'

[joerg van den hoff]

On 07.08.18 00:36, Richard Hipp wrote:
> On 8/6/18, joerg van den hoff  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 GOOD2018-07-19 15:52:43 aa17077eafbbad37
  6 GOOD2018-07-18 19:22:31 752ea432d1cf20fa
  4 GOOD2018-07-14 20:11:37 023ce4edde8ceb2d
  3 GOOD2018-06-23 15:48:49 aeb98be80f1d51f5
  2 GOOD2018-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