Re: [fossil-users] commits from host A sometimes not seen on B
On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers m.ramak...@gmail.comwrote: 2) update local repo on S 3) local repo on S doesn't show recent check-in, as per 'fossil timeline' 4) CGI-shared repo on S does show the check-in as per web interface timeline What is the time span between 2==3 and 3==4? i ask because i have one particular system which often takes several seconds to flush changes to disk. e.g. after compiling a new fossil binary, i sometimes have to wait 3 seconds before running the binary actually gets the new copy. i'm _speculating_ that if the timespan is short, then maybe it has to do with drive caching. Otherwise i'm just as confused as everyone else is regarding this behaviour. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal 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] commits from host A sometimes not seen on B
On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers m.ramak...@gmail.comwrote: I can make the 3 repos available for debugging (for Richard) on request, but I have a pretty thin uplink (but lots of space). How big are the repositories? Can you email them? -- 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] commits from host A sometimes not seen on B
On 14 October 2013 12:37, Stephan Beal sgb...@googlemail.com wrote: On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers m.ramak...@gmail.comwrote: 2) update local repo on S 3) local repo on S doesn't show recent check-in, as per 'fossil timeline' 4) CGI-shared repo on S does show the check-in as per web interface timeline What is the time span between 2==3 and 3==4? i ask because i have one particular system which often takes several seconds to flush changes to disk. e.g. after compiling a new fossil binary, i sometimes have to wait 3 seconds before running the binary actually gets the new copy. i'm _speculating_ that if the timespan is short, then maybe it has to do with drive caching. Otherwise i'm just as confused as everyone else is regarding this behaviour. I don't think that is it; when viewing the timeline on the server, I do see the check-in. It seems to me that the local repo on 'S' is not syncing from the CGI-available repo on 'S'. 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] commits from host A sometimes not seen on B
On 14 October 2013 12:38, Richard Hipp d...@sqlite.org wrote: On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers m.ramak...@gmail.com wrote: I can make the 3 repos available for debugging (for Richard) on request, but I have a pretty thin uplink (but lots of space). How big are the repositories? Can you email them? 400 something MB (per repo). I'd rather put them up for http on my host here, and email you the URLs. I can do that in an hour, say. 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] commits from host A sometimes not seen on B
On 14 October 2013 12:37, Stephan Beal sgb...@googlemail.com wrote: On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers m.ramak...@gmail.com wrote: 2) update local repo on S 3) local repo on S doesn't show recent check-in, as per 'fossil timeline' 4) CGI-shared repo on S does show the check-in as per web interface timeline What is the time span between 2==3 and 3==4? i ask because i have one particular system which often takes several seconds to flush changes to disk. e.g. after compiling a new fossil binary, i sometimes have to wait 3 seconds before running the binary actually gets the new copy. i'm _speculating_ that if the timespan is short, then maybe it has to do with drive caching. Otherwise i'm just as confused as everyone else is regarding this behaviour. time span between 2/3 = 10 sec (I did 'fossil timeline' approx 10 sec after I noticed the update showed the message for an older check-in). time span between 3/4 also = 10 sec. 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] commits from host A sometimes not seen on B
rephrase: On 14 October 2013 13:22, Michai Ramakers m.ramak...@gmail.com wrote: I don't think that is it; when viewing the timeline on the server, I do see the check-in. when viewing the timeline on the server, using the web interface ... 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] commits from host A sometimes not seen on B
On Mon, Oct 14, 2013 at 7:25 AM, Michai Ramakers m.ramak...@gmail.comwrote: On 14 October 2013 12:38, Richard Hipp d...@sqlite.org wrote: On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers m.ramak...@gmail.com wrote: I can make the 3 repos available for debugging (for Richard) on request, but I have a pretty thin uplink (but lots of space). How big are the repositories? Can you email them? 400 something MB (per repo). I'd rather put them up for http on my host here, and email you the URLs. I can do that in an hour, say. OK -- 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] commits from host A sometimes not seen on B
On 21 August 2013 05:25, Donny Ward donnyjw...@gmail.com wrote: I get the same problem every once in awhile. Many times actually. I consider myself a heavy fossil user. My most active repository has 1087 checkins all made by me. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext ... That sounds familiar. For the record, let me say I never (ever) make branches; all work here is done on trunk. The ticket you mention is 'fixed' stating a workaround like I did here; I'm not sure that is how it should be. (Not that reopening the ticket magically fixes the problem, but you give detailed and probably useful information there.) 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] commits from host A sometimes not seen on B
On Sun, Aug 18, 2013 at 05:20:35PM +0200, Michai Ramakers wrote: 1) on host S: clone project from host S (http://S/my_repo) 2) on host C: clone project from host S (http://S/my_repo) 3) on host C: do some work, and commit changes 4) on host S, 'fossil up' 5) on host S: 'fossil timeline' doesn't show the recent commit 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline' 7) on host C: do more work, and commit changes 8) on host 'S': 'fossil up'; now all recent commits are seen Perhaps relevant info: - autosync=1 on both sides - host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd - both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386 - fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC - fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC Just to add some anecdotal data to this . . . I've seen this behavior recently as well, in very similar circumstances. The major difference has been that both clients have autosync turned off, and do a manual sync before hacking on code, and either a pull before pushing commits or a manual sync. Running fossil update after a sync or pull that brings in changes that, in turn, do not show up in the client's checkout directory does not solve the problem, if I recall correctly. It has only happened a couple of times, and both times was fixed by a merge on one side or the other or a reclone. Unfortunately, I have not been able to determine whether any particular pattern of using manual sync or pull has an effect on this. Note that, as I said, it has not happened much, so I have not had much opportunity to identify the conditions specific to the manifestation of the problem with any certainty, apart from what I have mentioned above, which is why I had not composed a question myself about this issue yet. This situation concerns us because the workflow we use may lead to problems if a failure of Fossil to properly deliver commits leads to new code being added in a non-merged way without developers noticing. The server is running Fossil v1.26 (from ports) on FreeBSD 9.0 amd64, one client is running Fossil v1.26 (from ports) on FreeBSD 9.1 amd64, and the other client is running an unknown version of Fossil (from packages) on Arch Linux amd64, I believe, though I will check on the Fossil version when that developer is available and double-check the installed OS with him as well, and share that information if it is deemed relevant. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] commits from host A sometimes not seen on B
On Wed, Aug 21, 2013 at 08:37:43AM +0200, Michai Ramakers wrote: On 21 August 2013 05:25, Donny Ward donnyjw...@gmail.com wrote: I get the same problem every once in awhile. Many times actually. I consider myself a heavy fossil user. My most active repository has 1087 checkins all made by me. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext ... That sounds familiar. For the record, let me say I never (ever) make branches; all work here is done on trunk. In the repository where a fellow developer and I have seen this problem, there have been no intentional branches made, so add one to the numbers for this condition of the problem arising. The ticket you mention is 'fixed' stating a workaround like I did here; I'm not sure that is how it should be. (Not that reopening the ticket magically fixes the problem, but you give detailed and probably useful information there.) Indeed. The fix is in the behavior of one person's repository, and not in the intermittently manifesting issue with the operation of Fossil itself. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] commits from host A sometimes not seen on B
On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin c...@apotheon.net wrote: That sounds familiar. For the record, let me say I never (ever) make branches; all work here is done on trunk. In the repository where a fellow developer and I have seen this problem, there have been no intentional branches made, so add one to the numbers for this condition of the problem arising. The sync protocol for Fossil ( http://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki) pays no attention to check-ins or branching or tags or any other structure in the repository. The sync logic looks at the repository as an unordered bag of artifacts and it tries to make both participating repositories have the same set of artifacts. It treats the artifacts as opaque binary blobs. So, whatever this bug is, I'm guessing it does not have anything to do with branching. FWIW, the --verily option to fossil sync causes both participates to send igot cards for every artifact they hold (which can be tens or hundreds of thousands of artifacts). This seems to be sufficient to get both sides back into sync with one another. The downside is that with hundreds of thousands of artifacts, sending all those igot cards takes a lot of network traffic. The bug must be in one of the shortcuts by which Fossil normally avoids sending its complete set of igot cards. -- 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] commits from host A sometimes not seen on B
One thing to add here, is that when this happened for us, I had two different clones, one in a VM, and one on my workstation, and both of these couldn't see the 'faulty' commit until I re-cloned the repo (on both). So it seems to be a feature of the commit (or the copy that hits the server) rather than that of a particular checkout. Steve On Wed, Aug 21, 2013 at 2:03 PM, Richard Hipp d...@sqlite.org wrote: On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin c...@apotheon.net wrote: That sounds familiar. For the record, let me say I never (ever) make branches; all work here is done on trunk. In the repository where a fellow developer and I have seen this problem, there have been no intentional branches made, so add one to the numbers for this condition of the problem arising. The sync protocol for Fossil ( http://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki) pays no attention to check-ins or branching or tags or any other structure in the repository. The sync logic looks at the repository as an unordered bag of artifacts and it tries to make both participating repositories have the same set of artifacts. It treats the artifacts as opaque binary blobs. So, whatever this bug is, I'm guessing it does not have anything to do with branching. FWIW, the --verily option to fossil sync causes both participates to send igot cards for every artifact they hold (which can be tens or hundreds of thousands of artifacts). This seems to be sufficient to get both sides back into sync with one another. The downside is that with hundreds of thousands of artifacts, sending all those igot cards takes a lot of network traffic. The bug must be in one of the shortcuts by which Fossil normally avoids sending its complete set of igot cards. -- 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] commits from host A sometimes not seen on B
Hey Richard, I get the same problem every once in awhile. Many times actually. I consider myself a heavy fossil user. My most active repository has 1087 checkins all made by me. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext I have not noticed a pattern with the syncing problems. Going by feel, it feels like it occurs most frequently when I create a new branch, or if I edit a check-in comment. Also keep in mind that I rarely if ever have had sync errors. After every commit I would look at the remote repository to see if all the changes synced and they always do, except for these few cases. Also note that I always have auto-sync turned on. I used to host my repositories on a Linux VPS. I have since moved to Chisel and still have encountered sync problems. One time when the problem occured on my Linux VPS, I solved the problem by rebuilding the repository on the VPS side (the host repository). I dug around the source code of Fossil briefly to try and figure out the problem, and while I did not pinpoint it, I believed at the time that the issue had to do with the usage of clustered and unclustered artifacts. If I understand correctly, the used of these clusters is for a syncing optimization. However once I saw that you committed the --verily option, I stopped pursuing the problem because I was fairly confident that --verily solves the issue. Since my repository is hosted on Chisel, I will not find out until the next version is released and Chisel updates to that version. Also note that in ALL cases, the syncing problem can be solved by recloning the host repository. But I would prefer not to do that every time. I only used the fossil rebuild solution one time so I can't confidently say that it fixed the problem. And since I can't rebuild repositories on Chisel I can't try it with my current syncing problem. The problems have occured with and without HTTPS. So right now I actually have the syncing problem again. I created a new branch where I committed the entire source code to FreeType. This was done in a Linux VM. I then went to my Windows 8 desktop to update (keep in mind I have autosync always on) and it failed to pull the new branch; it's missing entirely from the timeline. It's also missing from my Macbook as well. So Mr. Hipp if you're interested, I can send you a copies of my repository to analyze and debug. However I would also need to get the current maintainer of Chisel to email me an untouched copy of my repository as it exists on that site right now. Does anyone have contact info for Chisel? The site still has James Turner's name on it. I would very much like for this bug to be fixed. Though --verily looks promising. Donny Ward ___ 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] commits from host A sometimes not seen on B
On Aug 20, 2013 8:25 PM, Donny Ward donnyjw...@gmail.com wrote: Hey Richard, I get the same problem every once in awhile. Many times actually. I consider myself a heavy fossil user. My most active repository has 1087 checkins all made by me. I once submitted a ticket about it here: http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext I have not noticed a pattern with the syncing problems. Going by feel, it feels like it occurs most frequently when I create a new branch, or if I edit a check-in comment. Also keep in mind that I rarely if ever have had sync errors. After every commit I would look at the remote repository to see if all the changes synced and they always do, except for these few cases. Also note that I always have auto-sync turned on. I used to host my repositories on a Linux VPS. I have since moved to Chisel and still have encountered sync problems. One time when the problem occured on my Linux VPS, I solved the problem by rebuilding the repository on the VPS side (the host repository). I dug around the source code of Fossil briefly to try and figure out the problem, and while I did not pinpoint it, I believed at the time that the issue had to do with the usage of clustered and unclustered artifacts. If I understand correctly, the used of these clusters is for a syncing optimization. However once I saw that you committed the --verily option, I stopped pursuing the problem because I was fairly confident that --verily solves the issue. Since my repository is hosted on Chisel, I will not find out until the next version is released and Chisel updates to that version. Also note that in ALL cases, the syncing problem can be solved by recloning the host repository. But I would prefer not to do that every time. I only used the fossil rebuild solution one time so I can't confidently say that it fixed the problem. And since I can't rebuild repositories on Chisel I can't try it with my current syncing problem. The problems have occured with and without HTTPS. So right now I actually have the syncing problem again. I created a new branch where I committed the entire source code to FreeType. This was done in a Linux VM. I then went to my Windows 8 desktop to update (keep in mind I have autosync always on) and it failed to pull the new branch; it's missing entirely from the timeline. It's also missing from my Macbook as well. So Mr. Hipp if you're interested, I can send you a copies of my repository to analyze and debug. However I would also need to get the current maintainer of Chisel to email me an untouched copy of my repository as it exists on that site right now. Does anyone have contact info for Chisel? The site still has James Turner's name on it. I think Andreas Kupries is the gentleman you want: andre...@activestate.com I would very much like for this bug to be fixed. Though --verily looks promising. Donny Ward ___ 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] commits from host A sometimes not seen on B
Richard, Using fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC. Command: fossil sync --verily Result: unknown repository: --verily Grepping the code I see the --verily option looks only applicable to the fossil scrub command. Is there a particular version that supports --verily for sync. Thanks, Clive On Sun, Aug 18, 2013 at 11:43 AM, Clive Hayward haywa...@chayward.comwrote: Richard, Would love to share repositories but would be violating my IP agreements:( So I'll need to try and trigger the problem with non-business data. Thanks for the reference to fossil sync --verily On Sun, Aug 18, 2013 at 11:36 AM, Richard Hipp d...@sqlite.org wrote: I think there is a bug in the sync algorithm that sometimes causes it to quit before both sides are fully synced up. But I don't yet have a reproducible test case, so it is a hard problem to fix. If you find a pair of repositories that are not fully syncing, please do this: (1) Make backup copies of the repositories on both sides of the exchange and make them available to me for debugging. (2) Run fossil sync --verily which is a heavy-duty sync that has a simpler design that uses more bandwidth but which is also much more likely to run to completion. A single fossil sync --verily is probably sufficient to get the two repos talking again after which ordinary syncs (without the --verily option) should be sufficient again. -- D. Richard Hipp d...@sqlite.org -- Clive Hayward -- Clive Hayward ___ 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] commits from host A sometimes not seen on B
On Mon, Aug 19, 2013 at 7:46 PM, Clive Hayward haywa...@chayward.comwrote: Richard, Using fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC. Command: fossil sync --verily Result: unknown repository: --verily Grepping the code I see the --verily option looks only applicable to the fossil scrub command. Is there a particular version that supports --verily for sync. That option is unreleased, so you'll have to compile from sources. That is easier than you might imagine. Instructions here: http://www.fossil-scm.org/fossil/doc/trunk/www/build.wiki -- 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] commits from host A sometimes not seen on B
On 2013-08-19 20:31, Richard Hipp wrote: That option is unreleased, so you'll have to compile from sources. That is easier than you might imagine. Instructions here: http://www.fossil-scm.org/fossil/doc/trunk/www/build.wiki It /must/ be. Even /I/ managed it! :) -- Thanks, DougF (KG4LMZ) ___ 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] commits from host A sometimes not seen on B
Oh, perhaps useful: viewing the timeline on host S using the web-interface (pointing to host S) at step (5) (or after step (6), not sure) showed the commit I was expecting to see. On 18 August 2013 17:20, Michai Ramakers m.ramak...@gmail.com wrote: Hello, I'm probably doing somethng strange, but has anyone ever seen this behaviour: 1) on host S: clone project from host S (http://S/my_repo) 2) on host C: clone project from host S (http://S/my_repo) 3) on host C: do some work, and commit changes 4) on host S, 'fossil up' 5) on host S: 'fossil timeline' doesn't show the recent commit 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline' 7) on host C: do more work, and commit changes 8) on host 'S': 'fossil up'; now all recent commits are seen Perhaps relevant info: - autosync=1 on both sides - host 'S' serves a bunch of fossils through fossil using cgi-mode, from inetd - both hosts running a recent NetBSD; host 'S' is amd64, host 'C' is i386 - fossil version on host C: 1.26 [3ca6979514] 2013-07-23 18:57:25 UTC - fossil version on host S: 1.25 [a6dad6508c] 2013-06-14 07:19:58 UTC I can't reproduce this, but if someone has ideas to try the next time this happens I'd be happy to try. I can rebuild fossil on one or both hosts, but I have the feeling this is something very basic. Related question: I typically use 'fossil up', and never 'fossil sync' (or pull/push) in my workflow, working on 2 hosts on the same project - should I? 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] commits from host A sometimes not seen on B
On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.comwrote: 1) on host S: clone project from host S (http://S/my_repo) 2) on host C: clone project from host S (http://S/my_repo) 3) on host C: do some work, and commit changes 4) on host S, 'fossil up' 5) on host S: 'fossil timeline' doesn't show the recent commit 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline' 7) on host C: do more work, and commit changes 8) on host 'S': 'fossil up'; now all recent commits are seen It sounds almost like you have autosync turned off - do 'up' and 'pull' show any network traffic? - autosync=1 on both sides But you've already verified that. Related question: I typically use 'fossil up', and never 'fossil sync' (or pull/push) in my workflow, working on 2 hosts on the same project - should I? That doesn't sound wrong. If autosync is on there is rarely a need for push/pull. Do an 'up' when you start working, to make sure you aren't working from what would become a fork, and it will sync/push when you commit (if autosync is on). i hope someone can help you resolve this - i also suspect that the problem will turn out to be something simple/silly. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commits from host A sometimes not seen on B
On 18 August 2013 17:43, Stephan Beal sgb...@googlemail.com wrote: On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.com wrote: 1) on host S: clone project from host S (http://S/my_repo) 2) on host C: clone project from host S (http://S/my_repo) 3) on host C: do some work, and commit changes 4) on host S, 'fossil up' 5) on host S: 'fossil timeline' doesn't show the recent commit 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline' 7) on host C: do more work, and commit changes 8) on host 'S': 'fossil up'; now all recent commits are seen It sounds almost like you have autosync turned off - do 'up' and 'pull' show any network traffic? Tbh I forgot - the error-situation is gone now, sadly. Related question: I typically use 'fossil up', and never 'fossil sync' (or pull/push) in my workflow, working on 2 hosts on the same project - should I? That doesn't sound wrong. If autosync is on there is rarely a need for push/pull. Do an 'up' when you start working, to make sure you aren't working from what would become a fork, and it will sync/push when you commit (if autosync is on). Right. If it comes up again, I'll try to keep it as-is, if that's possible, and post it on here - who knows. 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] commits from host A sometimes not seen on B
We had a similar situation last week: Fossil server hosting many repos, two active clients on one repo. Clients A and B were both working on the same branch simultaneously. Client A commits (commit 1) Client B tries to commit, gets conflict warning. Client B runs fossil update Client B commits successfully Timeline on server shows two leaves with the same tag. Client B never sees commit 1.. Running any combination of pull update rebuild does not work. The commit message for 1 is not present in the database. In the end, I resolved this by re-cloning from the server. Note we've been doing parallel commits on the branch for a while. And this has only happened once, both clients use auto sync. I was going to chalk this up to cosmic particles or similar, but it sounds as of it might be related. Thanks Steve On 18 Aug 2013 16:51, Michai Ramakers m.ramak...@gmail.com wrote: On 18 August 2013 17:43, Stephan Beal sgb...@googlemail.com wrote: On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.com wrote: 1) on host S: clone project from host S (http://S/my_repo) 2) on host C: clone project from host S (http://S/my_repo) 3) on host C: do some work, and commit changes 4) on host S, 'fossil up' 5) on host S: 'fossil timeline' doesn't show the recent commit 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline' 7) on host C: do more work, and commit changes 8) on host 'S': 'fossil up'; now all recent commits are seen It sounds almost like you have autosync turned off - do 'up' and 'pull' show any network traffic? Tbh I forgot - the error-situation is gone now, sadly. Related question: I typically use 'fossil up', and never 'fossil sync' (or pull/push) in my workflow, working on 2 hosts on the same project - should I? That doesn't sound wrong. If autosync is on there is rarely a need for push/pull. Do an 'up' when you start working, to make sure you aren't working from what would become a fork, and it will sync/push when you commit (if autosync is on). Right. If it comes up again, I'll try to keep it as-is, if that's possible, and post it on here - who knows. Michai ___ 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] commits from host A sometimes not seen on B
I have experienced a similar problem as Steve on several occasions. To fix the problem I've been rebuilding the server repository and then merging on the server. Then the clients can pull to get in sync. Clive On Sun, Aug 18, 2013 at 9:25 AM, Stestagg stest...@gmail.com wrote: We had a similar situation last week: Fossil server hosting many repos, two active clients on one repo. Clients A and B were both working on the same branch simultaneously. Client A commits (commit 1) Client B tries to commit, gets conflict warning. Client B runs fossil update Client B commits successfully Timeline on server shows two leaves with the same tag. Client B never sees commit 1.. Running any combination of pull update rebuild does not work. The commit message for 1 is not present in the database. In the end, I resolved this by re-cloning from the server. Note we've been doing parallel commits on the branch for a while. And this has only happened once, both clients use auto sync. I was going to chalk this up to cosmic particles or similar, but it sounds as of it might be related. Thanks Steve On 18 Aug 2013 16:51, Michai Ramakers m.ramak...@gmail.com wrote: On 18 August 2013 17:43, Stephan Beal sgb...@googlemail.com wrote: On Sun, Aug 18, 2013 at 5:20 PM, Michai Ramakers m.ramak...@gmail.com wrote: 1) on host S: clone project from host S (http://S/my_repo) 2) on host C: clone project from host S (http://S/my_repo) 3) on host C: do some work, and commit changes 4) on host S, 'fossil up' 5) on host S: 'fossil timeline' doesn't show the recent commit 6) on host S: 'fossil pull' doesn't show the commit either in 'fossil timeline' 7) on host C: do more work, and commit changes 8) on host 'S': 'fossil up'; now all recent commits are seen It sounds almost like you have autosync turned off - do 'up' and 'pull' show any network traffic? Tbh I forgot - the error-situation is gone now, sadly. Related question: I typically use 'fossil up', and never 'fossil sync' (or pull/push) in my workflow, working on 2 hosts on the same project - should I? That doesn't sound wrong. If autosync is on there is rarely a need for push/pull. Do an 'up' when you start working, to make sure you aren't working from what would become a fork, and it will sync/push when you commit (if autosync is on). Right. If it comes up again, I'll try to keep it as-is, if that's possible, and post it on here - who knows. Michai ___ 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 -- Clive Hayward ___ 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] commits from host A sometimes not seen on B
did any of you (Steve/Clive) by any chance try committing once more (a dummy-change or similar) on what Steve has named client A (the client whose commit is never seen by the other host)? (And if so, did both it and the missing commit show up?) 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] commits from host A sometimes not seen on B
Michai, In more than one instance a subsequent commit was performed on one of the clients (unaware that there was an issue). That commit was visible to the other client only after the server repository was rebuilt. Clive On Sun, Aug 18, 2013 at 10:28 AM, Michai Ramakers m.ramak...@gmail.comwrote: did any of you (Steve/Clive) by any chance try committing once more (a dummy-change or similar) on what Steve has named client A (the client whose commit is never seen by the other host)? (And if so, did both it and the missing commit show up?) Michai ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Clive Hayward ___ 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] commits from host A sometimes not seen on B
On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward haywa...@chayward.comwrote: Michai, In more than one instance a subsequent commit was performed on one of the clients (unaware that there was an issue). That commit was visible to the other client only after the server repository was rebuilt. i've had a couple cases which sound similar but were explainable. i would make a commit, the push would fail because my network was out or whatever, and i wouldn't notice it. Later on i'd wonder where my commit was. That's happened to me a handful of times over the years. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] commits from host A sometimes not seen on B
Stephan, Although I haven't been able to consistently reproduce the errors. These were definitely not network errors. The steps involve. 1) Client A makes a commit. 2) Client B makes a commit - but is warned that they will fork. 3) Client B updates - but doesn't appear to get Client A's commit. 4) Client B commits with no error and the server forks. 5) Client C updates but only gets Client A or B's commit but not both. At this point fossil rebuild on the server. Clients can update and can see the other leafs. On Sun, Aug 18, 2013 at 10:58 AM, Stephan Beal sgb...@googlemail.comwrote: On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward haywa...@chayward.comwrote: Michai, In more than one instance a subsequent commit was performed on one of the clients (unaware that there was an issue). That commit was visible to the other client only after the server repository was rebuilt. i've had a couple cases which sound similar but were explainable. i would make a commit, the push would fail because my network was out or whatever, and i wouldn't notice it. Later on i'd wonder where my commit was. That's happened to me a handful of times over the years. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal -- Clive Hayward ___ 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] commits from host A sometimes not seen on B
On Sun, Aug 18, 2013 at 8:12 PM, Clive Hayward haywa...@chayward.comwrote: 5) Client C updates but only gets Client A or B's commit but not both. All i can say to that is, yeah, that's weird. Unfortunately not terribly helpful. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
