Re: [fossil-users] commits from host A sometimes not seen on B
On Mon, Oct 14, 2013 at 7:25 AM, Michai Ramakers wrote: > On 14 October 2013 12:38, Richard Hipp wrote: > > > > On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers > 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
rephrase: On 14 October 2013 13:22, Michai Ramakers 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 14 October 2013 12:37, Stephan Beal wrote: > > On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers > 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
On 14 October 2013 12:38, Richard Hipp wrote: > > On Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers 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 wrote: > On Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers 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. > > 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 Mon, Oct 14, 2013 at 6:17 AM, Michai Ramakers 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? -- 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 Mon, Oct 14, 2013 at 12:17 PM, Michai Ramakers 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. -- - 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
[fossil-users] commits from host A sometimes not seen on B
[ following up on oldish thread from mid August this year, with the same subject ] I've just seen this issue here, albeit in slightly another form perhaps (2 systems 'S' (server, amd64 netbsd) and 'C' (client, WinXP pro). 'S' makes a repo available using CGI/inetd, and I work on 'S' locally as well, with a local repo cloned from "http://S/myrepo.fossil";. Autosync is on for local repos on 'C' and 'S'. I did the following: 1) check-in on C 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 5) make copies of C local repo, S local repo, S CGI-shared repo for analysis 6) fetch/build latest fossil, build, and run 'fossil sync --verily' on S local repo 7) all is fine; recent check-in is seen Stupidly, I didn't try a plain "fossil sync" or "update" after building. I can still do this by reverting to the saved archives, tonight (probably). I can make the 3 repos available for debugging (for Richard) on request, but I have a pretty thin uplink (but lots of space). 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
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 wrote: > On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin 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
On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin 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
On Wed, Aug 21, 2013 at 08:37:43AM +0200, Michai Ramakers wrote: > On 21 August 2013 05:25, Donny Ward 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 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 21 August 2013 05:25, Donny Ward 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 Aug 20, 2013 8:25 PM, "Donny Ward" 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
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 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
On Mon, Aug 19, 2013 at 7:46 PM, Clive Hayward wrote: > 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
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 wrote: > 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 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
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 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 ___ 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 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 ___ 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 wrote: > 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
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 wrote: > On Sun, Aug 18, 2013 at 7:35 PM, Clive Hayward wrote: > >> 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 7:35 PM, Clive Hayward wrote: > 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
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 wrote: > 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
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
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 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" wrote: > >> On 18 August 2013 17:43, Stephan Beal wrote: >> > On Sun, Aug 18, 2013 at 5:20 PM, 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 >> > >> > >> > 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
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" wrote: > On 18 August 2013 17:43, Stephan Beal wrote: > > On Sun, Aug 18, 2013 at 5:20 PM, 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 > > > > > > 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
On 18 August 2013 17:43, Stephan Beal wrote: > On Sun, Aug 18, 2013 at 5:20 PM, 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 > > > 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
On Sun, Aug 18, 2013 at 5:20 PM, 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 > 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
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 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
[fossil-users] commits from host A sometimes not seen on B
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
