Re: [fossil-users] Tracking System Configuration Files - Best Practices
Could i convince one of the devs more familiar with the symlinks bits refine Joerg's explanation below into one of the embedded docs? It's a pretty good explanation/summary, IMO. On Fri, May 9, 2014 at 8:33 PM, j. van den hoff veedeeh...@googlemail.comwrote: On Fri, 09 May 2014 19:45:01 +0200, Matt Welland estifo...@gmail.com wrote: FYI, beware that there may be a bug with symlinks support in the more recent versions of fossil. I haven't reported it as I haven't had time to reproduce it but a couple of users have complained that when they clone/open a fossil that has allow-symlinks = true that the symlinks are replaced by the pointed to data in the check out. If they check out an older node then check out trunk the data is replaced by the expected symlinks. I'm not sure whether there is a bug here (except the one noted at the end of this mail). my reading of `fossil help set' and a small test I've done right now with This is fossil version 1.29 [5e47d555e4] 2014-04-30 16:35:21 UTC (note to developers: the `This is' in the version message should go away in my view -- at least it would allow more seamless copy+paste not disrupting the syntax of the text into which one copies ;-)) seems to verify this behaviour: 1. allow-symlinks off (default): a) if the symlinks are ADDed and checkedin, content is tracked across the links, i.e. as far as fossil is concerned everything acts as if the actual files where local to the repo: changes are noted, checkouts overwrite the actual files, not the symlinks. this seems in accord with the documentation and sure is useful for the purpose of tracking disseminated config files, e.g. b) if this repo is cloned and opened, indeed the original files materialize in the checkout, i.e. the symlink information is lost (probably never was there in the repo?). I presume(...) this also does not contradict the documentation. this seems to be the behavior you mention. but this is not wrong per se. whether this behavior is ideal is another question. one probably could argue for restoring symlinks at this point. 2. allow-symlinks on: a) if the symlinks are ADDed and checkedin, content is NOT tracked across the links, i.e. modifications of the linked files are not noticed by fossil and cannot be checked in. the content of the checkedin links (e.g. what you see with `fossil cat') just is the path to the linked files. this seems in accord with the documentation b) if this repo is cloned and opened, links materialize using verbatim the path stored as content in the original repo. all this seems quite consistent to me also 1.b) might not be what one would prefer. the only probably real bug for me is that in 2.b) above the generated symlinks point _verbatim_ to the same location used in the original creation of the links (instead of always using the absolute paths). here is the catch: if the links were not generated with absolute pathnames in the first place, the links in the clone usually will point to outer space (i.e. the links are invalid) which is totally useless I'd say. j. On Fri, May 9, 2014 at 10:00 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, May 9, 2014 at 6:30 PM, j. van den hoff veedeeh...@googlemail.com wrote: modified. so my understanding is when 'on' the softlinks are just maintained in the repo while when 'off' (the default) the system should behave like what you describe: track the changes across the softlinks (i.e. the real content) and update _that_ content when doing a `fossil up'. or am I missing something? i didn't think about that, but i'm almost certain (almost!) you're right. That's my understanding from having skipped over symlinks support in libfossil so far. That means that symlinks support is not what you want for this purpose. Real symlinks to the files, but symlinks support explicitly turned off, should serve the basic purpose - having the content of those files in the repo. IIRC, if symlinks support is off, checking out the repo initially will create a file under the checkout dir with the contents of the linked-to file. i think. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal 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 -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal Freedom is sloppy. But since tyranny's the only
Re: [fossil-users] Fossil process hanging on sync to remote server?
On Sat, May 10, 2014 at 1:03 AM, Stephan Beal sgb...@googlemail.com wrote:
For me fossil builds with -g (debug) flags by default, so you shouldn't
have to rebuild.
I ended up recompiling fossil just to be sure. On Mac OSX Mavericks, gdb
has been replaced by lldb.
I managed to get the process to hang again (it hadn't completed in over 10
minutes during a sync). I attached to it and went looking up the frames one
by one.
Here are the frames:
frame #0: 0x7fff8aef59f0 libsystem_kernel.dylib`read + 8
frame #1: 0x7fff8fbfd84c libcrypto.0.9.8.dylib`conn_read + 76
frame #2: 0x7fff8fbf7264 libcrypto.0.9.8.dylib`BIO_read + 100
frame #3: 0x7fff86b6513d libssl.0.9.8.dylib`ssl3_read_n + 365
frame #4: 0x7fff86b65b9f libssl.0.9.8.dylib`ssl3_read_bytes + 735
frame #5: 0x7fff86b63dec libssl.0.9.8.dylib`ssl3_read + 156
frame #6: 0x7fff86b4e4c9 libssl.0.9.8.dylib`ssl_read + 73
frame #7: 0x7fff8fbf7264 libcrypto.0.9.8.dylib`BIO_read + 100
frame #8: 0x000105719ba2 fossil`ssl_receive(NotUsed=unavailable,
pContent=unavailable, N=unavailable) + 50 at http_ssl.c:399
396 size_t got;
397 size_t total = 0;
398 while( N0 ){
- 399 got = BIO_read(iBio, pContent, N);
400 if( got=0 ) break;
401 total += got;
402 N -= got;
So, it's hanging in the BIO_read function.
Global/static variables (command: ta v) are:
(SSL_CTX *) sslCtx = 0x7fa1c2e039b0
(char *) sslErrMsg = 0x
(SSL *) ssl = 0x7fa1c2e04430
(BIO *) iBio = 0x7fa1c2e043c0
Frame variables (fr v) are unfortunately:
(void *) NotUsed = variable not available
(void *) pContent = variable not available
(size_t) N = variable not available
(size_t) total = 0
(size_t) got = variable not available
Going up a couple more frames gives context to where in the code it is
stalling but I'm not sure whether it gives any insight to why. Perhaps if
someone could give some guidance on how I can investigate further I can
help diagnose. Here are the remaining frames all the way up to main:
frame #9: 0x00010571a3a6 fossil`transport_fetch(pUrlData=unavailable,
zBuf=0x7fa1c2e078b0, N=1000) + 102 at http_transport.c:311
308 }
309 }else if( pUrlData-isHttps ){
310 #ifdef FOSSIL_ENABLE_SSL
- 311 got = ssl_receive(0, zBuf, N);
312 #else
313 got = 0;
314 #endif
(lldb) up
frame #10: 0x00010571a548 fossil`transport_receive_line [inlined]
transport_load_buffer(pUrlData=0x00010589f430) + 236 at
http_transport.c:393
390 transport.pBuf = pNew;
391 }
392 if( N0 ){
- 393 i = transport_fetch(pUrlData, transport.pBuf[transport.nUsed],
N);
394 if( i0 ){
395 transport.nRcvd += i;
396 transport.nUsed += i;
(lldb) up
frame #11: 0x00010571a45c
fossil`transport_receive_line(pUrlData=0x00010589f430) + 76 at
http_transport.c:416
413 i = iStart = transport.iCursor;
414 while(1){
415 if( i = transport.nUsed ){
- 416 transport_load_buffer(pUrlData, pUrlData-isSsh ? 2 : 1000);
417 i -= iStart;
418 iStart = 0;
419 if( i = transport.nUsed ){
(lldb) up
frame #12: 0x000105718815
fossil`http_exchange(pSend=0x7fff5a518640, pReply=0x7fff5a518620,
useLogin=1, maxRedirect=20) + 1301 at http.c:206
203 */
204 closeConnection = 1;
205 iLength = -1;
- 206 while( (zLine = transport_receive_line(GLOBAL_URL()))!=0
zLine[0]!=0 ){
207 /* printf([%s]\n, zLine); fflush(stdout); */
208 if( fossil_strnicmp(zLine, http/1., 7)==0 ){
209 if( sscanf(zLine, HTTP/1.%d %d, iHttpVersion, rc)!=2 )
goto write_err;
(lldb) up
frame #13: 0x00010576b1e3 fossil`client_sync(syncFlags=unavailable,
configRcvMask=unavailable, configSendMask=unavailable) + 1955 at
xfer.c:1560
1557}
1558fflush(stdout);
1559/* Exchange messages with the server */
- 1560if( http_exchange(send, recv, (syncFlags SYNC_CLONE)==0 ||
nCycle0,
1561MAX_REDIRECTS) ){
1562 nErr++;
1563 break;
(lldb) up
frame #14: 0x00010574d2a9 fossil`autosync(flags=unavailable) + 313 at
sync.c:75
72if( find_option(verbose,v,0)!=0 ) flags |= SYNC_VERBOSE;
73fossil_print(Autosync: %s\n, g.urlCanonical);
74url_enable_proxy(via proxy: );
- 75rc = client_sync(flags, configSync, 0);
76if( rc ) fossil_warning(Autosync failed);
77return rc;
78 }
(lldb) up
frame #15: 0x0001056f9f85 fossil`commit_cmd + 5365 at checkin.c:1927
1924 db_end_transaction(0);
1925
1926 if( !g.markPrivate ){
- 1927autosync(SYNC_PUSH|SYNC_PULL);
1928 }
1929 if( count_nonbranch_children(vid)1 ){
1930fossil_print( warning: a fork has occurred *\n);
(lldb) up
frame #16: 0x000105726195 fossil`main(argc=unavailable,
argv=unavailable) + 2325 at main.c:701
698 fossil_exit(1);
699 }
700 atexit( fossil_atexit );
- 701 aCommand[idx].xFunc();
702 fossil_exit(0);
Re: [fossil-users] minor libfossil milestone: TH1-style web page
On Fri, May 9, 2014 at 10:16 PM, Stephan Beal sgb...@googlemail.com wrote: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/tmplish?showSrc=1 is basically the basis of such a functionality. This one combines templates with server-side widgets: http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/widgets http://fossil.wanderinghorse.net/repos/libfossil/cgidemo/index.cgi/widgets?showSrc=1 -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal 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] Fossil process hanging on sync to remote server?
On 10/05/14 10:53, Gerald Gutierrez wrote:
[---]
pContent=unavailable, N=unavailable) + 50 at http_ssl.c:399
396 size_t got;
397 size_t total = 0;
398 while( N0 ){
- 399 got = BIO_read(iBio, pContent, N);
400 if( got=0 ) break;
401 total += got;
402 N -= got;
So, it's hanging in the BIO_read function.
...which is probably blocking and waiting for data. Either it's
supposed to wait for data which the other side isn't sending (a problem
at the other side?), or it has gotten the idea that it needs more data
even though it doesn't (a local problem?). I'd start by taking a look
at what the other side is doing.
Is it possible for you to test without SSL?
--
Kind Regards,
Jan
___
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] Fossil process hanging on sync to remote server?
Thus said Gerald Gutierrez on Sat, 10 May 2014 01:53:56 -0700:
frame #8: 0x000105719ba2 fossil`ssl_receive(NotUsed=unavailable,
pContent=unavailable, N=unavailable) + 50 at http_ssl.c:399
396 size_t got;
397 size_t total = 0;
398 while( N0 ){
- 399 got = BIO_read(iBio, pContent, N);
400 if( got=0 ) break;
401 total += got;
402 N -= got;
So, it's blocking in the BIO_read function. Hard to say why without more
data about both ends. netstat -na (on both sides) will probably provide
some interesting information (e.g. are there blocks of data queued in
either Recv-Q or Send-Q on either end of the ESTABLISHED connection).
gdb on the remote fossil would provide some other details.
I did find this particular comment about using BIO_read and non-blocking
I/O in OpenBSD's manpage (specifically the last sentence):
One technique sometimes used with blocking sockets is to use
a system call (such as select(), poll() or equivalent) to
determine when data is available and then call read() to read
the data. The equivalent with BIOs (that is call select() on
the underlying I/O structure and then call BIO_read() to read
the data) should not be used because a single call to
BIO_read() can cause several reads (and writes in the case of
SSL BIOs) on the underlying I/O structure and may block as a
result. Instead select() (or equivalent) should be combined
with non blocking I/O so successive reads will request a
retry instead of blocking.
I'm not sure if using this technique would fare any better without
understanding why it's blocking. Is there a firewall reacting to
something it doesn't like? Some other network problem that exists like
lost packets? Does it only happen when using cron? If so, why?
Andy
--
TAI64 timestamp: 4000536e49ee
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
