Re: [fossil-users] Fossil update
Thus said Zolt?n K?csi on Wed, 07 Nov 2018 20:48:11 +1100: > 'fossil update' (autosync/push/pull enabled) updates the local tree > but not to the latest version. This sounds like a cluster synchronization bug that was squashed after Fossil 1.29 was released: https://www.fossil-scm.org/index.html/timeline?c=2014-07-22+22:26:50 Check your ``fossil version'' to be certain. If it is indeed the same bug, then you can use ``fossil pull --verily'' to pull down the missing content. Andy -- TAI64 timestamp: 40005be44f6c ___ 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
On Nov 7, 2018, at 6:18 AM, Zoltán Kócsi wrote: > > For some projects we used colour-coding of the Timeline entries, for > example releases were coloured differently from developers-only commits > and so on. That all seems to have gone. If you upgraded your central repository server from 1.29 to 2.7 to fix the problem suggested by drh — someone’s been checking in SHA3-hashed artifacts — then you also have to update your skin. If you were using the stock skin before, just go into Admin > Skins and select the Default skin again. You might have to switch to some other skin and back to get it to overwrite your outdated skin files. If you made changes to your local skin, you’ll have to merge the changes made to the default version of the skin you started with into your local version. In versions 2.5 and 2.7, there were a lot of changes to the default skin, some of which were done to track changes made to the HTML emitted by “fossil server” in support of newer features. Outdated skins won’t style the new HTML properly. ___ 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
On 11/7/18, Zoltán Kócsi wrote: > > For some projects we used colour-coding of the Timeline entries, for > example releases were coloured differently from developers-only commits > and so on. That all seems to have gone. > > Also, the Timeline now seems to show only one branch at a time while the > old version has shown all changes and different branches were > represented by different colours and a graphically displayed line. Those features should be unchanged. If you visit the canonical Fossil self-hosting repo (https://fossil-scm.org/fossil/timeline) or the SQLite Fossil repository (https://sqlite.org/src/timeline) you can see that both of those show all branches using color codes. I do not know what might be causing your problem. Can you provide an example? -- 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
Richard, > > Is the latest Fossil binary compatible with the 1.29 version on the > > repo file level? > > Yes. Thanks! It worked fine. However, a quick question: For some projects we used colour-coding of the Timeline entries, for example releases were coloured differently from developers-only commits and so on. That all seems to have gone. Also, the Timeline now seems to show only one branch at a time while the old version has shown all changes and different branches were represented by different colours and a graphically displayed line. That made a side-by-side tracking of different branches a breeze without needing to compare dates while switching between branches back and forth. Are those features really gone or in the new Fossil you need to explicitly turn them on or it's just that my ancient browser (I update browsers about as frequently as I update Fossil) can't cope with some new HTML5 whizz-bang that Fossil now uses? Thanks, Best Regards, Zoltan ___ 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
On 11/7/18, Zoltán Kócsi wrote: > > Is the latest Fossil binary compatible with the 1.29 version on the > repo file level? That is, will it be able to read the old SQLite file > and modify/update its schema to the latest version without losing > anything? Yes. In fact, I don't recall any major schema changes going from 1.x to 2.x. The big change there, and the reason for the major version number bump, was adding support for SHA3 hashes. 1.x supported only SHA1 hashes. 2.x supports both SHA1 and SHA3. Thus 2.x will read and understand 1.x repos, but 1.x cannot decode 2.x repos. If I had to guess (with so little information) about why you are not seeming to sync, I would suspect that somebody in your organization is using a 2.x version of Fossil and has done one or more commits that use a SHA3 hash. The older 1.x versions cannot understand that and are pretending those checkins do not exist. -- 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 --latest not working
On Thu, Apr 7, 2016 at 5:04 AM, John Regehr wrote: > Argh, thanks, sorry for the noise! > > John > > > On 4/7/16 2:02 PM, Richard Hipp wrote: > >> On 4/7/16, John Regehr wrote: >> >>> What is the branch tag reported by fossil status? Perhaps the branch you were on got renamed? >>> >>> It says this: >>> >>> tags: pager-get-noinit >>> >>> whereas I had previously been on the trunk. Is that expected that I >>> will be silently moved between branches? >>> >>> >> Normally Fossil does not move between branches. Except, if you use >> the --latest option, it will move to the most latest descendent of the >> current check-out, regardless of the branch. So probably what >> happened is that you did "fossil up --latest" at a time when the >> pager-get-noinit branch was the latest descendent of the trunk >> check-in that you were previously on. But pager-get-noinit is >> currently a dead-end. (Maybe we'll merge it to trunk later, or maybe >> not - still undecided on that.) And so subsequent "fossil up >> --latest" commands do not move you off of that check-in because that >> check-in currently has no descendants. >> > >From a design-for-humans perspective I think fossil should stick to the branch *name*. The least surprising thing is to end up on the tip of the branch where you were working previously, not on the tip of some new branch. If I'm working on "trunk" and do a fossil update and end up on "some-debug-branch" I will be confused. The symbolic name is the critical data here IMHO. > >> If you want to move to the latest trunk check-in, then the command to >> use is "fossil update trunk". >> >> ___ > 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 --latest not working
On 4/7/2016 5:02 AM, Richard Hipp wrote: On 4/7/16, John Regehr wrote: Is that expected that I will be silently moved between branches? Normally Fossil does not move between branches. Except, if you use the --latest option, it will move to the most latest descendent of the current check-out, regardless of the branch If you want to move to the latest trunk check-in, then the command to use is "fossil update trunk". That answers a nagging question I'd had: What is the difference between "fossil update --latest" and "fossil update tip"? Answer: "tip" is the very last checkin to any branch, while "--latest" is the very last checkin descending from "current". So now my question is what can we do to the wording of the help for update that makes the actual meaning of --latest clearer? It currently says: Usage: %fossil update ?OPTIONS? ?VERSION? ?FILES...? The VERSION argument can be a specific version or tag or branch name. If the VERSION argument is omitted, then the leaf of the subtree that begins at the current version is used, if there is only a single leaf. VERSION can also be "current" to select the leaf of the current version or "latest" to select the most recent check-in. Options: --latest acceptable in place of VERSION, update to latest version One thing that should be at least hinted at here is that using anything other than "fossil update" or "fossil update current" (which are exact synonyms) *can* move you to a different branch, and unless you are deliberately attempting to change to a different branch that move is likely to be surprising. It should probably also say that "--latest" and "latest" are the same thing. As it is worded now, the two ways of describing it seem to hint at a difference that isn't there. I'll take a crack at rewriting that "soon", but if anyone else has ideas I'm all ears... -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ 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 --latest not working
Argh, thanks, sorry for the noise! John On 4/7/16 2:02 PM, Richard Hipp wrote: On 4/7/16, John Regehr wrote: What is the branch tag reported by fossil status? Perhaps the branch you were on got renamed? It says this: tags: pager-get-noinit whereas I had previously been on the trunk. Is that expected that I will be silently moved between branches? Normally Fossil does not move between branches. Except, if you use the --latest option, it will move to the most latest descendent of the current check-out, regardless of the branch. So probably what happened is that you did "fossil up --latest" at a time when the pager-get-noinit branch was the latest descendent of the trunk check-in that you were previously on. But pager-get-noinit is currently a dead-end. (Maybe we'll merge it to trunk later, or maybe not - still undecided on that.) And so subsequent "fossil up --latest" commands do not move you off of that check-in because that check-in currently has no descendants. If you want to move to the latest trunk check-in, then the command to use is "fossil update trunk". ___ 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 --latest not working
On 4/7/16, John Regehr wrote: >> What is the branch tag reported by fossil status? Perhaps the branch you >> were on got renamed? > > It says this: > > tags: pager-get-noinit > > whereas I had previously been on the trunk. Is that expected that I > will be silently moved between branches? > Normally Fossil does not move between branches. Except, if you use the --latest option, it will move to the most latest descendent of the current check-out, regardless of the branch. So probably what happened is that you did "fossil up --latest" at a time when the pager-get-noinit branch was the latest descendent of the trunk check-in that you were previously on. But pager-get-noinit is currently a dead-end. (Maybe we'll merge it to trunk later, or maybe not - still undecided on that.) And so subsequent "fossil up --latest" commands do not move you off of that check-in because that check-in currently has no descendants. If you want to move to the latest trunk check-in, then the command to use is "fossil update trunk". -- 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 --latest not working
What is the branch tag reported by fossil status? Perhaps the branch you were on got renamed? It says this: tags: pager-get-noinit whereas I had previously been on the trunk. Is that expected that I will be silently moved between branches? Sorry if I'm asking dumb questions-- I'm really just trying to keep my interactions with fossil to a minimum while staying up to date with the latest sqlite sources. Thanks, John ___ 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 --latest not working
On Thu, Apr 7, 2016 at 4:45 AM, Scott Robison wrote: > What is the branch tag reported by fossil status? Perhaps the branch you > were on got renamed? > > On Thu, Apr 7, 2016 at 2:43 AM, John Regehr wrote: > >> Hi Andy, >> >> I'm returning to this topic because I again have a repo that got "stuck". >> >> Please see the interaction with fossil below. I ran "fossil update >> --latest" and it received 53 artifacts, but didn't end up updating and of >> my local files. And in fact, a diff between a fresh checkout of sqlite and >> the repo below shows that I don't have the latest changes. My experience is >> that a repo that gets stuck in this fashion will continue to receive >> artifacts from the server but will never again update my local files with >> fresh content. >> > Sorry for the premature / top posted reply previously. Anyway, if you are not on trunk, fossil update --latest will only take you to the latest commit on whatever branch you are on. If a branch was renamed, you'll be some place other than where you expected. ___ 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 --latest not working
What is the branch tag reported by fossil status? Perhaps the branch you were on got renamed? On Thu, Apr 7, 2016 at 2:43 AM, John Regehr wrote: > Hi Andy, > > I'm returning to this topic because I again have a repo that got "stuck". > > Please see the interaction with fossil below. I ran "fossil update > --latest" and it received 53 artifacts, but didn't end up updating and of > my local files. And in fact, a diff between a fresh checkout of sqlite and > the repo below shows that I don't have the latest changes. My experience is > that a repo that gets stuck in this fashion will continue to receive > artifacts from the server but will never again update my local files with > fresh content. > > Thanks, > > John > > > > john@TrustInSoft-Box-V:~$ cd sqlite/ > john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest > Autosync: http://www.sqlite.org/cgi/src > Round-trips: 3 Artifacts sent: 0 received: 53 > Pull done, sent: 2148 received: 33277 ip: 67.18.92.124 > > --- > checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01 > UTC > tags: pager-get-noinit > comment: Avoid unnecessary memset() operations in sqlite3PagerGet(). > (user: drh) > changes: None. Already up-to-date > john@TrustInSoft-Box-V:~/sqlite$ > john@TrustInSoft-Box-V:~/sqlite$ > john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest > Autosync: http://www.sqlite.org/cgi/src > Round-trips: 1 Artifacts sent: 0 received: 0 > Pull done, sent: 289 received: 658 ip: 67.18.92.124 > > --- > checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01 > UTC > tags: pager-get-noinit > comment: Avoid unnecessary memset() operations in sqlite3PagerGet(). > (user: drh) > changes: None. Already up-to-date > john@TrustInSoft-Box-V:~/sqlite$ > > > > > > On 3/8/16 3:47 PM, Andy Bradford wrote: > >> Thus said John Regehr on Tue, 08 Mar 2016 10:18:15 +0100: >> >> This usually works, but every couple of weeks my local repository gets >>> somehow stuck in a state where the remote changes appear to be pulled >>> from the server, but then they are not applied to my local sources. >>> This has happened about 4 times. >>> >> >> Can you be a little more specific about what this means? For example, do >> you see the remote changes in the timeline in your local repository and >> Fossil simply does not update your open checkout to those versions of >> the file? Or do you not see the changes at all? >> >> Can you provide some output from the commands you're running when this >> problem happens? >> >> Thanks, >> >> Andy >> >> ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- Scott Robison ___ 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 --latest not working
Hi Andy, I'm returning to this topic because I again have a repo that got "stuck". Please see the interaction with fossil below. I ran "fossil update --latest" and it received 53 artifacts, but didn't end up updating and of my local files. And in fact, a diff between a fresh checkout of sqlite and the repo below shows that I don't have the latest changes. My experience is that a repo that gets stuck in this fashion will continue to receive artifacts from the server but will never again update my local files with fresh content. Thanks, John john@TrustInSoft-Box-V:~$ cd sqlite/ john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest Autosync: http://www.sqlite.org/cgi/src Round-trips: 3 Artifacts sent: 0 received: 53 Pull done, sent: 2148 received: 33277 ip: 67.18.92.124 --- checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01 UTC tags: pager-get-noinit comment: Avoid unnecessary memset() operations in sqlite3PagerGet(). (user: drh) changes: None. Already up-to-date john@TrustInSoft-Box-V:~/sqlite$ john@TrustInSoft-Box-V:~/sqlite$ john@TrustInSoft-Box-V:~/sqlite$ fossil update --latest Autosync: http://www.sqlite.org/cgi/src Round-trips: 1 Artifacts sent: 0 received: 0 Pull done, sent: 289 received: 658 ip: 67.18.92.124 --- checkout: 0c97b80240b38d60236cd8e1e51954b20f147eed 2016-04-05 00:44:01 UTC tags: pager-get-noinit comment: Avoid unnecessary memset() operations in sqlite3PagerGet(). (user: drh) changes: None. Already up-to-date john@TrustInSoft-Box-V:~/sqlite$ On 3/8/16 3:47 PM, Andy Bradford wrote: Thus said John Regehr on Tue, 08 Mar 2016 10:18:15 +0100: This usually works, but every couple of weeks my local repository gets somehow stuck in a state where the remote changes appear to be pulled from the server, but then they are not applied to my local sources. This has happened about 4 times. Can you be a little more specific about what this means? For example, do you see the remote changes in the timeline in your local repository and Fossil simply does not update your open checkout to those versions of the file? Or do you not see the changes at all? Can you provide some output from the commands you're running when this problem happens? Thanks, Andy ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] fossil update --latest not working
Thus said John Regehr on Tue, 08 Mar 2016 10:18:15 +0100: > This usually works, but every couple of weeks my local repository gets > somehow stuck in a state where the remote changes appear to be pulled > from the server, but then they are not applied to my local sources. > This has happened about 4 times. Can you be a little more specific about what this means? For example, do you see the remote changes in the timeline in your local repository and Fossil simply does not update your open checkout to those versions of the file? Or do you not see the changes at all? Can you provide some output from the commands you're running when this problem happens? Thanks, Andy -- TAI64 timestamp: 400056dee638 ___ 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 --latest not working
Thanks for the help Martin and Stephan! Unfortunately I already nuked the stuck repository. However, I will save a copy next time this happens, it seems somewhat predicable. John On 3/8/16 12:28 PM, Martin Gagnon wrote: Le 8 mars 2016 à 05:23, Stephan Beal mailto:sgb...@googlemail.com>> a écrit : On Tue, Mar 8, 2016 at 10:18 AM, John Regehr mailto:reg...@cs.utah.edu>> wrote: I have an extremely simply use case for fossil: I'm tracking the latest sqlite sources but I have some modifications in my local repository. Every few days I run "fossil update --latest". This usually works, but every couple of weeks my local repository gets somehow stuck in a state where the remote changes appear to be pulled from the server, but then they are not applied to my local sources. This has happened about 4 times. When the problem occurs it is persistent and I need to save my patches off on the side and re-clone the sqlite archive. Please try changing the update to a combination of (pull --verily) and (update --latest). In the past (pull --verily) has helped work around similar problems (AFAIK, the root of that particular problem has never been discovered, but it crops up once in a while on the mailing list.) Please, before to do that, make a copy of your repository file in that state. Just in case someone from this list want it to find the root of the problem later. This problem happens rarely and if I remember it use to be on private repository that couldn't be share. -- Martin G. ___ 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 --latest not working
> Le 8 mars 2016 à 05:23, Stephan Beal a écrit : > >> On Tue, Mar 8, 2016 at 10:18 AM, John Regehr wrote: >> I have an extremely simply use case for fossil: I'm tracking the latest >> sqlite sources but I have some modifications in my local repository. Every >> few days I run "fossil update --latest". This usually works, but every >> couple of weeks my local repository gets somehow stuck in a state where the >> remote changes appear to be pulled from the server, but then they are not >> applied to my local sources. This has happened about 4 times. When the >> problem occurs it is persistent and I need to save my patches off on the >> side and re-clone the sqlite archive. > > Please try changing the update to a combination of (pull --verily) and > (update --latest). In the past (pull --verily) has helped work around similar > problems (AFAIK, the root of that particular problem has never been > discovered, but it crops up once in a while on the mailing list.) > Please, before to do that, make a copy of your repository file in that state. Just in case someone from this list want it to find the root of the problem later. This problem happens rarely and if I remember it use to be on private repository that couldn't be share. -- Martin G.___ 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 --latest not working
On Tue, Mar 8, 2016 at 10:18 AM, John Regehr wrote: > I have an extremely simply use case for fossil: I'm tracking the latest > sqlite sources but I have some modifications in my local repository. Every > few days I run "fossil update --latest". This usually works, but every > couple of weeks my local repository gets somehow stuck in a state where the > remote changes appear to be pulled from the server, but then they are not > applied to my local sources. This has happened about 4 times. When the > problem occurs it is persistent and I need to save my patches off on the > side and re-clone the sqlite archive. > Please try changing the update to a combination of (pull --verily) and (update --latest). In the past (pull --verily) has helped work around similar problems (AFAIK, the root of that particular problem has never been discovered, but it crops up once in a while on the mailing list.) -- - 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 wrote: > On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon 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
On Fri, Apr 25, 2014 at 8:45 AM, Ory Drilon 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
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 Thu, Apr 24, 2014 at 10:36 AM, j. van den hoff 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
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 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
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
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
On 23 April 2014 18:28, Andreas Kupries 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 9:15 AM, Stephan Beal wrote: > On Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries > 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 Wed, Apr 23, 2014 at 6:12 PM, Andreas Kupries 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 :/. -- - 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 wrote: > On Wed, Apr 23, 2014 at 9:18 AM, Samuel Debionne > 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 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 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
> 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
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
On Tue, Apr 22, 2014 at 9:30 PM, Andy Bradford wrote: > 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
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 1:03 PM, Stephan Beal wrote: > On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland 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
On Tue, Apr 22, 2014 at 9:47 PM, Matt Welland 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 9:36 AM, Stephan Beal 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 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 11:51 AM, Michai Ramakers wrote: > 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
> 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
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
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 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: Total network traffic does not add up
On Sat, Apr 14, 2012 at 4:30 AM, Jos Groot Lipman wrote: > ** > I did a recent update of my fossil repository. It shows that a total of > 4243 bytes were sent and 95998 bytes were received. > However if I add the numbers in the bytes column I get 6395 and 181518 > bytes, almost double the amount. > > Why the difference? Is one compressed and the other uncompressed? > The individual Sent and Received lines are measuring uncompressed content. The total is showing the actual compressed byte-count sent over-the-wire. > > d:\Software\Fossil>fossil update > Autosync: http://www.fossil-scm.org/ > Bytes Cards Artifacts Deltas > Sent: 177 2 0 0 > Received:3712 81 0 0 > Sent:3937 82 0 0 > Received: 153580161 7 73 > Sent:2104 43 0 0 > Received: 20514122 1 40 > Sent: 177 2 0 0 > Received:3712 81 0 0 > Total network traffic: 4243 bytes sent, 95998 bytes received > > > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > -- 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 FAIL
Ok, Didn't realize there was a disconnected Leaf in the remote repo. c:\myrepo> fossil merge 88d803c051 worked. We still are unsure what created the disconnect? Though we seem to have hiccups when upgrading the fossil.exe and doing rebuilds on both local and remote repos. On Tue, Aug 30, 2011 at 7:10 PM, wrote: > Hi, > I ran into a snag today after a week away on vacation. > This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC > > I performed a pull. > c:\myrepo> fossil pull t:\myrepo\myrepo1.fossil > ...lots of changes came down the network... > Bytes Cards Artifacts Deltas > Sent: 130 1 0 0 > Received: 2056 45 0 0 > Sent: 1023 20 0 0 > Received: 11346 64 0 19 > Total network traffic: 957 bytes sent, 6805 bytes received > > I then ran an update. > c:\myrepo> fossil update > ...nothing happened. no report? > ...But I assumed my checkout contained the latest changes. > ...So I began to edit my code and noticed none of the changes were there. > > Question: What should I do in this case? > > I eventually got things aligned with 2 cycles of close/open. > Not sure why? > I ran a close. > c:\myrepo> fossil close > > I ran an open. > c:\myrepo> fossil open myrepo.fossil > ...Still no update of my folder contents! > Repeat worked. > > Maybe if I automated this via a script, I would have stopped > immediately after receiving no report on the update? > > Thanks for your help. > ___ 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 FAIL
Hi, I ran into a snag today after a week away on vacation. This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC I performed a pull. c:\myrepo> fossil pull t:\myrepo\myrepo1.fossil ...lots of changes came down the network... Bytes Cards Artifacts Deltas Sent: 130 1 0 0 Received: 2056 45 0 0 Sent: 1023 20 0 0 Received: 11346 64 0 19 Total network traffic: 957 bytes sent, 6805 bytes received I then ran an update. c:\myrepo> fossil update ...nothing happened. no report? ...But I assumed my checkout contained the latest changes. ...So I began to edit my code and noticed none of the changes were there. Question: What should I do in this case? I eventually got things aligned with 2 cycles of close/open. Not sure why? I ran a close. c:\myrepo> fossil close I ran an open. c:\myrepo> fossil open myrepo.fossil ...Still no update of my folder contents! Repeat worked. Maybe if I automated this via a script, I would have stopped immediately after receiving no report on the update? Thanks for your help. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users