Re: [fossil-users] Fossil update goes not get lastest checkin
Is there a known problem with time skew in the first place? Maybe resolving that would fix these untraceable phantoms. I also bumped into something similar when hosting the same .fossil on two different servers with a time skew between them. Everything was fine when I fixed the time settings, though I logged an extra comment to ticket 683457aa0f in case it would be useful. i'm wondering if perhaps your server had system event and the clock was skewed for a brief period. That's probably impossible to know for sure now. Perhaps the clock on the host NFS system is slower than the one on your mac? Perhaps a time mis-sync is causing this? ___ 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 update goes not get lastest checkin
On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon o...@drilon.com wrote: Is there a known problem with time skew in the first place? Maybe resolving that would fix these untraceable phantoms. Not that i'm aware of - i was speculating that maybe the clock was used as an optimization for the client to ask the server has anything arrives since time X, but i don't think that actually happens. I also bumped into something similar when hosting the same .fossil on two different servers with a time skew between them. Everything was fine when I fixed the time settings, though I logged an extra comment to ticket 683457aa0f in case it would be useful. The timeline will do funny things in a time skew, but it otherwise should not cause any real grief. -- - 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 update goes not get lastest checkin
On Fri, Apr 25, 2014 at 8:32 AM, Stephan Beal sgb...@googlemail.com wrote: On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon o...@drilon.com wrote: Is there a known problem with time skew in the first place? Maybe resolving that would fix these untraceable phantoms. Not that i'm aware of - i was speculating that maybe the clock was used as an optimization for the client to ask the server has anything arrives since time X, but i don't think that actually happens. The sync algorithm does not use timestamps. So clock skew should not effect sync in any way. -- 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] Fossil update goes not get lastest checkin
just for the record, I believe I encountered something similar: I have a very simple setup: a remote (cgi-served) repo (acting essentially only as a backup but publicly accessible) and _one_ local clone where only _one_ user (me) does checkins (the owner of the remote server _could_ clone/do checkins but he doesn't...). autosync is 'off' right now, so I do the `sync/push' manually (by habit I use `sync' although `push' would suffice since no one _ever_ does an independent checkin to the server-side repo (no other clone, no local developer on the server) and I do not expect incoming changes. so what I have observed a week ago was some hickup (I don't recall what exactly, either a failed `sync' or `push') and retried (probably at that point `sync'). I then discovered a fork popping up in the timeline which, moreover, confusingly was some ten days in the past (the timeline had already progressed several commits after the fork). I don't see any reason why (and any way how) this fork could have occurred. maybe this additional observation helps to get this missing commit phenomenon sorted out -- it really is a bit scary even if nothing really bad is happening to the repo content. if you want to have a look, the repo is freely accessible here: http://j...@fossil.0branch.com/sd (maybe the repo content is even of some interest to someone ...) the fork in question is [a8cbddcfc3]. In the meantime I have closed it explicitly and edited the checkin comment (the latter I did directly in the server-side repo where I've chosen a different user name than for the local clone). the original ci-comment was identical to that of [efd8772a0b] (and it's diff vs. [88f8514b9f] is a subset of the diff of [efd8772a0b] vs. [88f8514b9f]). I could not make head nor tail of this. I also cannot rule out completely that I am responsible for the fork (making some stupid error) but really cannot imagine how and that it has nothing to do with the problems discussed in this thread. but maybe it does ... j. On Thu, 24 Apr 2014 07:20:56 +0200, Andy Bradford amb-fos...@bradfords.org wrote: Thus said Michai Ramakers on Wed, 23 Apr 2014 18:34:32 +0200: I have no clue on sync logic at all, but perhaps this helps: in all cases I remember here (3 or so), when sync of commit on host A was not seen during sync on host B, doing a dummy-commit on host A, then pulling again on B, worked, i.e. last 2 commits from A were pulled. This sounds almost identical to the problem that I described that is caused by a failed autosync except there is no mention of fork happening. The fork may or may not happen if the branches were different. But, committing after a failed sync will certainly cause another autosync and then the push with the new changes will cause the missing content to show up. Andy -- 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
Re: [fossil-users] Fossil update goes not get lastest checkin
On Thu, Apr 24, 2014 at 10:36 AM, j. van den hoff veedeeh...@googlemail.com wrote: maybe this additional observation helps to get this missing commit phenomenon sorted out -- it really is a bit scary even if nothing really bad is happening to the repo content. It is indeed, but until we can see it happening we can only guess as to what might actually cause it :(. My setups are almost 100% identical to yours - CGI repos mostly used by one user (except that i use autosync because i forget to push if i don't). i've been using Fossil daily for over 6 years and haven't seen this happen even once. Enough people have, though, that it's obviously happening. the fork in question is [a8cbddcfc3]. In the meantime I have closed it explicitly and edited the checkin comment (the latter I did directly in the server-side repo where I've chosen a different user name than for the local clone). the original ci-comment was identical to that of [efd8772a0b] (and it's diff vs. [88f8514b9f] is a subset of the diff of [efd8772a0b] vs. [88f8514b9f]). i'm wondering if perhaps your server had system event and the clock was skewed for a brief period. That's probably impossible to know for sure now. I could not make head nor tail of this. I also cannot rule out completely that I am responsible for the fork (making some stupid error) but really cannot imagine how and that it has nothing to do with the problems discussed in this thread. but maybe it does ... It does indeed sound somewhat related. -- - 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 update goes not get lastest checkin
Thus said Matt Welland on Tue, 22 Apr 2014 22:22:16 -0700: This has happened enough that I'm sure it was a real issue but it has been long enough since anyone reported it to me that I'd assumed it was fixed. Unfortunately, nobody has been able to reproduce so it's kind of hard to fix. The closest I could get was the problem I described. Andy -- TAI64 timestamp: 400053576491 ___ 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 update goes not get lastest checkin
Out of curiosity: is there a proxy between them? A caching proxy server might explain this behaviour (in which case i think there's a workaround). No proxy involved. The three machines are sitting on my desk. As a side note, the server is a raspberry PI and it does a great job at hosting fossil repo ! I have seen this issue a few times and this was with using file:// for the transport to the server. I've fixed it by doing a checkout to another branch and back. If I recall correctly a checkout to the current branch was not enough but I'm not sure. I'm using https transport layer (lighty web server handles the SSL part, the fossil CGI interface is used). The three machines are clock sync with NTP. The only clue for you I have is that a rebuild on the server did the trick. I'm no sure what fossil rebuild does though... ___ 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 update goes not get lastest checkin
On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne samuel.debio...@ujf-grenoble.fr wrote: The only clue for you I have is that a rebuild on the server did the trick. I'm no sure what fossil rebuild does though... Rebuild basically reconstructs the db from its underlying metadata. A very brief introduction: fossil stored basically 3 types of things: a) the so-called Manifests, which are formal records of changes. b) the file content which (A) refers to c) a whole bunch of _transient_ relational data which is created based on (A). A rebuild basically deletes (C) then regenerates it from (A). (C) includes things like the timeline, the parent/child relationships, and basically anything which can be derived from the low-level (A) parts. The docs for (A) are here: http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki (They're only interesting if you're into really geeky details, though.) A snippet from some arbitrary manifest might help clarify: [stephan@host:~/cvs/fossil/libfossil]$ f-acat current | head B d846a10d99c1e169c7587c8dc2a67170eae8a1d7 C minor\sdoc\saddition. D 2014-04-22T20:19:58.256 F f-apps/f-sanity.c e3e21327062f3a39c7109ce41ce616fd2a9b772c F f-apps/f-status.c 0c6d8e9420594f21e75ff86ede758ac7d35217bf F include/fossil-scm/fossil-cli.h c3c46f81009d410eff793d68311a769f58a5abc5 F include/fossil-scm/fossil-db.h a19862f0994b865a76831140b25f1c3cedab83a0 F include/fossil-scm/fossil-internal.h 1ca2e6dabf769a4a6bab21805e21b8ba515beb7e F include/fossil-scm/fossil-util.h 0b765f7960e0b09286e8cd399d00cf86c8f71ee5 F src/fsl.c acce29830dd3d56053d9ee81169c51c3ede60a2d ... All those SHA1 hashes refer to items in the (B) data set. Some of them (the ones starting with F) are file content and some (e.g. the B part) refer to other metadata from (A) (which is stored in (B), actually). The B part refers to another checkin version from which this one derives certain metadata. We can take one of those UUID at random and get its content: [stephan@host:~/cvs/fossil/libfossil]$ f-acat e3e21327062f3a39c7109ce41ce616fd2a9b772c | head -5 /* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /* vim: set ts=2 et sw=2 tw=80: */ /* Copyright (c) 2013-2014 D. Richard Hipp ... -- - 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 update goes not get lastest checkin
On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne samuel.debio...@ujf-grenoble.fr wrote: No proxy involved. The three machines are sitting on my desk. As a side note, the server is a raspberry PI and it does a great job at hosting fossil repo ! ... The three machines are clock sync with NTP. Then i am still at an utter loss. -- - 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 update goes not get lastest checkin
On Wed, Apr 23, 2014 at 8:38 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne samuel.debio...@ujf-grenoble.fr wrote: The only clue for you I have is that a rebuild on the server did the trick. I'm no sure what fossil rebuild does though... Rebuild basically reconstructs the db from its underlying metadata. A very brief introduction: fossil stored basically 3 types of things: a) the so-called Manifests, which are formal records of changes. b) the file content which (A) refers to c) a whole bunch of _transient_ relational data which is created based on (A). A rebuild basically deletes (C) then regenerates it from (A). (C) includes things like the timeline, the parent/child relationships, and basically anything which can be derived from the low-level (A) parts. The docs for (A) are here: I am wondering if the rebuild will also redo the cluster artifacts. They are for sync optimization, i.e. telling the other side in a single hash that a group of manifests is present. If these are done wrongly, it may very well cause the receiver to believe that it has stuff which it doesn't. http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki (They're only interesting if you're into really geeky details, though.) A snippet from some arbitrary manifest might help clarify: [stephan@host:~/cvs/fossil/libfossil]$ f-acat current | head B d846a10d99c1e169c7587c8dc2a67170eae8a1d7 C minor\sdoc\saddition. D 2014-04-22T20:19:58.256 F f-apps/f-sanity.c e3e21327062f3a39c7109ce41ce616fd2a9b772c F f-apps/f-status.c 0c6d8e9420594f21e75ff86ede758ac7d35217bf F include/fossil-scm/fossil-cli.h c3c46f81009d410eff793d68311a769f58a5abc5 F include/fossil-scm/fossil-db.h a19862f0994b865a76831140b25f1c3cedab83a0 F include/fossil-scm/fossil-internal.h 1ca2e6dabf769a4a6bab21805e21b8ba515beb7e F include/fossil-scm/fossil-util.h 0b765f7960e0b09286e8cd399d00cf86c8f71ee5 F src/fsl.c acce29830dd3d56053d9ee81169c51c3ede60a2d ... All those SHA1 hashes refer to items in the (B) data set. Some of them (the ones starting with F) are file content and some (e.g. the B part) refer to other metadata from (A) (which is stored in (B), actually). The B part refers to another checkin version from which this one derives certain metadata. We can take one of those UUID at random and get its content: [stephan@host:~/cvs/fossil/libfossil]$ f-acat e3e21327062f3a39c7109ce41ce616fd2a9b772c | head -5 /* -*- Mode: C; tab-width: 4; indent-tabs-mode: nil; c-basic-offset: 2 -*- */ /* vim: set ts=2 et sw=2 tw=80: */ /* Copyright (c) 2013-2014 D. Richard Hipp ... -- - 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 -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster(tm) F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ ___ 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 update goes not get lastest checkin
On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries andre...@activestate.comwrote: I am wondering if the rebuild will also redo the cluster artifacts. i have no idea - i'm not at all familiar with the sync-related code (because it's way down on the list of libfossil's TODOs ;). If these are done wrongly, it may very well cause the receiver to believe that it has stuff which it doesn't. It's a starting point, which is more than we've had so far :/. -- - 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 update goes not get lastest checkin
On Wed, Apr 23, 2014 at 9:15 AM, Stephan Beal sgb...@googlemail.com wrote: On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries andre...@activestate.com wrote: I am wondering if the rebuild will also redo the cluster artifacts. i have no idea - i'm not at all familiar with the sync-related code (because it's way down on the list of libfossil's TODOs ;). If these are done wrongly, it may very well cause the receiver to believe that it has stuff which it doesn't. It's a starting point, which is more than we've had so far :/. Another would be to see what the --verily is doing differently from regular sync. For ex. does it bypass the cluster optimizations ? I.e. any code bypassed by --verily would be suspect -- Andreas Kupries Senior Tcl Developer Code to Cloud: Smarter, Safer, Faster(tm) F: 778.786.1133 andre...@activestate.com http://www.activestate.com Learn about Stackato for Private PaaS: http://www.activestate.com/stackato EuroTcl'2014, July 12-13, Munich, GER -- http://www.eurotcl.tcl3d.org/ 21'st Tcl/Tk Conference: Nov 10-14, Portland, OR, USA -- http://www.tcl.tk/community/tcl2014/ ___ 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 update goes not get lastest checkin
On 23 April 2014 18:28, Andreas Kupries andre...@activestate.com wrote: Another would be to see what the --verily is doing differently from regular sync. For ex. does it bypass the cluster optimizations ? I.e. any code bypassed by --verily would be suspect I have no clue on sync logic at all, but perhaps this helps: in all cases I remember here (3 or so), when sync of commit on host A was not seen during sync on host B, doing a dummy-commit on host A, then pulling again on B, worked, i.e. last 2 commits from A were pulled. Michai ___ 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 update goes not get lastest checkin
On Wed, Apr 23, 2014 at 09:12:28AM -0700, Andreas Kupries wrote: I am wondering if the rebuild will also redo the cluster artifacts. No, but it does rebuild the phantom table, a.k.a. the missing artifacts. 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] Fossil update goes not get lastest checkin
Thus said Michai Ramakers on Wed, 23 Apr 2014 18:34:32 +0200: I have no clue on sync logic at all, but perhaps this helps: in all cases I remember here (3 or so), when sync of commit on host A was not seen during sync on host B, doing a dummy-commit on host A, then pulling again on B, worked, i.e. last 2 commits from A were pulled. This sounds almost identical to the problem that I described that is caused by a failed autosync except there is no mention of fork happening. The fork may or may not happen if the branches were different. But, committing after a failed sync will certainly cause another autosync and then the push with the new changes will cause the missing content to show up. Andy -- TAI64 timestamp: 400053589f5b ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Fossil update goes not get lastest checkin
Hello all, Here is a sequence I'm doing several times a day for years and that did not work this morning : fossil commit -m Blabla from my PC fossil update from my Mac But this time the update did not get the latest checkin. A complete clone / open in a different directory was OK though. I had to rebuild the repository on the server to make it work. Any ideas why ? Samuel ___ 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 update goes not get lastest checkin
Hello, not sure if this is the same issue you're seeing, but this has come up here a few times - commits not seen on pull/sync from different host. There's a '--verily' option to 'sync' iirc, to work around what may be a bug; see for example this mail thread: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12979.html. I'm not sure the issue has been solved in the meanwhile. (I haven't seen missing commits since that post.) Michai On 22 April 2014 11:36, Samuel Debionne samuel.debio...@ujf-grenoble.fr wrote: Hello all, Here is a sequence I'm doing several times a day for years and that did not work this morning : fossil commit -m Blabla from my PC fossil update from my Mac But this time the update did not get the latest checkin. A complete clone / open in a different directory was OK though. I had to rebuild the repository on the server to make it work. Any ideas why ? Samuel ___ 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] Fossil update goes not get lastest checkin
Thus said Samuel Debionne on Tue, 22 Apr 2014 11:36:46 +0200: Here is a sequence I'm doing several times a day for years and that did not work this morning : fossil commit -m Blabla from my PC fossil update from my Mac Has a fork happened? Have a look at the timeline and see if there is a fork somewhere that would have caused your current checkout to be different from what you might expect. Did the sync fail on a push from somewhere and what you expect to be there isn't quite there? Just some thoughts, not sure if these are relevant. Andy -- TAI64 timestamp: 400053567af6 ___ 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 update goes not get lastest checkin
There's a '--verily' option to 'sync' iirc, to work around what may be a bug; see for example this mail thread: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12979.html. I'm not sure the issue has been solved in the meanwhile. (I haven't seen missing commits since that post.) Did not know about the '--verily' option. As you say in your post, if it comes up again, I'll try to keep it as-is, if that's possible, and post it on here. ___ 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 update goes not get lastest checkin
On Tue, Apr 22, 2014 at 11:51 AM, Michai Ramakers m.ramak...@gmail.comwrote: not sure if this is the same issue you're seeing, but this has come up here a few times - commits not seen on pull/sync from different host. There's a '--verily' option to 'sync' iirc, to work around what may be a bug; see for example this mail thread: https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg12979.html . I'm not sure the issue has been solved in the meanwhile. (I haven't seen missing commits since that post.) Just to confirm that: this has come up several times before in the past year and, so far, has remained unexplained. We're not sure what causes it or how to reproduce it. (At least i don't remember seeing any commits/posts which explain/fix it.) -- - 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 update goes not get lastest checkin
On Tue, Apr 22, 2014 at 11:36 AM, Samuel Debionne samuel.debio...@ujf-grenoble.fr wrote: fossil commit -m Blabla from my PC fossil update from my Mac But this time the update did not get the latest checkin. Out of curiosity: is there a proxy between them? A caching proxy server might explain this behaviour (in which case i think there's a workaround). (e.g. when web-deploying client-side Java applications in enterprise environments, caching proxies often cause some clients to be served older JAR files until the cache expires or is reset.) -- - 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 update goes not get lastest checkin
On Tue, Apr 22, 2014 at 9:36 AM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Apr 22, 2014 at 11:36 AM, Samuel Debionne samuel.debio...@ujf-grenoble.fr wrote: fossil commit -m Blabla from my PC fossil update from my Mac But this time the update did not get the latest checkin. Out of curiosity: is there a proxy between them? A caching proxy server might explain this behaviour (in which case i think there's a workaround). I have seen this issue a few times and this was with using file:// for the transport to the server. I've fixed it by doing a checkout to another branch and back. If I recall correctly a checkout to the current branch was not enough but I'm not sure. (e.g. when web-deploying client-side Java applications in enterprise environments, caching proxies often cause some clients to be served older JAR files until the cache expires or is reset.) -- - 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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 update goes not get lastest checkin
On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland estifo...@gmail.com wrote: I have seen this issue a few times and this was with using file:// for the transport to the server. I've fixed it by doing a checkout to another branch and back. If I recall correctly a checkout to the current branch was not enough but I'm not sure. That's interesting. So the repo is on an NFS share. Perhaps the clock on the host NFS system is slower than the one on your mac? Perhaps a time mis-sync is causing this? -- - 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 update goes not get lastest checkin
On Tue, Apr 22, 2014 at 1:03 PM, Stephan Beal sgb...@googlemail.com wrote: On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland estifo...@gmail.com wrote: I have seen this issue a few times and this was with using file:// for the transport to the server. I've fixed it by doing a checkout to another branch and back. If I recall correctly a checkout to the current branch was not enough but I'm not sure. That's interesting. So the repo is on an NFS share. Perhaps the clock on the host NFS system is slower than the one on your mac? Perhaps a time mis-sync is causing this? Sorry, no Mac involved :) Linux all the way. I'm not sure how time skew could cause this. In every case that I recall there were commits stored in the fossil db that were more recent than the current checkout but fossil update seemed not to see them. If it happens again I'll try to preserve things to reproduce it. What is the update algorithm using for a deciding basis, node time or parent-child relationship? One thing that may be related is that if there is a fork and you do an update fossil does not move to the latest node on the appropriate tine of the fork. This is both silent - i.e. the user has no feedback and must look at the node id and timeline to figure out what is going on, and a hassle because to merge the fork you need to use checkout to get to the tip of the tine. In brief it seems that fossil is not moving along the timeline on update in some cases where it could and this might be the logic that is being triggered by the rare fails to update bug. -- - 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 -- Matt -=- 90% of the nations wealth is held by 2% of the people. Bummer to be in the majority... ___ 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 update goes not get lastest checkin
Thus said Stephan Beal on Tue, 22 Apr 2014 18:07:08 +0200:
Just to confirm that: this has come up several times before in the
past year and, so far, has remained unexplained. We're not sure what
causes it or how to reproduce it. (At least i don't remember seeing
any commits/posts which explain/fix it.)
The only time I've ever seen it *not* update to the latest commit in a
remote repository is when a sync has failed. For example:
$ ../fossil ci -m bottom
Autosync: ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 2 Artifacts sent: 0 received: 18
Pull finished with 1063 bytes sent, 298025 bytes received
New_Version: 18febd6eb320521d5b730d237381d001b562496e
Autosync: ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 1 Artifacts sent: 2 received: 0
Error: Database error: database is locked: {INSERT INTO rcvfrom(uid, mtime,
nonce, ipaddr)VALUES(1, julianday('now'), NULL, '192.168.1.5')}
Round-trips: 1 Artifacts sent: 2 received: 0
Sync finished with 1586 bytes sent, 290 bytes received
Autosync failed
$ ../fossil up
Autosync: ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 3 Artifacts sent: 0 received: 84
Pull finished with 3012 bytes sent, 1355913 bytes received
---
checkout: 18febd6eb320521d5b730d237381d001b562496e 2014-04-23 04:18:45 UTC
tags: trunk
comment: bottom (user: amb)
changes: None. Already up-to-date
But I know that 18fe is not the tip of trunk. If I manually tell it to
update to 5f75 it will update. Also, because the sync failed, I don't
see my commit on the remote repository yet. Once I do a sync it shows up
though, and after I sync I actually see that a fork has occurred.
Is this the same issue that others are seeing? Hard to say, but it's the
only time I've observed any kind of failure to update.
Andy
--
TAI64 timestamp: 400053574221
___
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 update goes not get lastest checkin
On Tue, Apr 22, 2014 at 9:30 PM, Andy Bradford amb-fos...@bradfords.orgwrote:
Thus said Stephan Beal on Tue, 22 Apr 2014 18:07:08 +0200:
Just to confirm that: this has come up several times before in the
past year and, so far, has remained unexplained. We're not sure what
causes it or how to reproduce it. (At least i don't remember seeing
any commits/posts which explain/fix it.)
The only time I've ever seen it *not* update to the latest commit in a
remote repository is when a sync has failed. For example:
$ ../fossil ci -m bottom
Autosync: ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 2 Artifacts sent: 0 received: 18
Pull finished with 1063 bytes sent, 298025 bytes received
New_Version: 18febd6eb320521d5b730d237381d001b562496e
Autosync: ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 1 Artifacts sent: 2 received: 0
Error: Database error: database is locked: {INSERT INTO rcvfrom(uid,
mtime, nonce, ipaddr)VALUES(1, julianday('now'), NULL, '192.168.1.5')}
Round-trips: 1 Artifacts sent: 2 received: 0
Sync finished with 1586 bytes sent, 290 bytes received
Autosync failed
$ ../fossil up
Autosync: ssh://remote//tmp/test.fossil?fossil=/tmp/fossil
Round-trips: 3 Artifacts sent: 0 received: 84
Pull finished with 3012 bytes sent, 1355913 bytes received
---
checkout: 18febd6eb320521d5b730d237381d001b562496e 2014-04-23 04:18:45
UTC
tags: trunk
comment: bottom (user: amb)
changes: None. Already up-to-date
But I know that 18fe is not the tip of trunk. If I manually tell it to
update to 5f75 it will update. Also, because the sync failed, I don't
see my commit on the remote repository yet. Once I do a sync it shows up
though, and after I sync I actually see that a fork has occurred.
Is this the same issue that others are seeing? Hard to say, but it's the
only time I've observed any kind of failure to update.
I haven't seen this problem in quite a while but what we saw was the sync
had occurred and yet we couldn't update to the tip. I had suspected this
issue was solved, perhaps indirectly or by other development. It is rare
enough and easy enough to work around that other than reporting it I
haven't worried about it. Unfortunately in every case it happened the repo
in question contained data that could not be shared so I couldn't provide a
testcase.
This has happened enough that I'm sure it was a real issue but it has been
long enough since anyone reported it to me that I'd assumed it was fixed.
Andy
--
TAI64 timestamp: 400053574221
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
--
Matt
-=-
90% of the nations wealth is held by 2% of the people. Bummer to be in the
majority...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
