Re: [fossil-users] documentation clarification
On Wed, Feb 1, 2012 at 8:03 AM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. I was in a situation where this was happening regularly. I got warnings about the clocks being out of sync from fossil. I'm no longer in that situation (and traveling), so I can't easily test it, but isn't that still the case? mike ___ 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] documentation clarification
On Feb 1, 2012, at 15:18 , Chris Peachment wrote: I can't speak for MS-Windows or MacOS but Ubuntu Linux uses NTP by default. So does OS X. Kind regards, Remigiusz Modrzejewski ___ 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] documentation clarification
On Wed, Feb 1, 2012 at 4:42 AM, Leo Razoumov slonik...@gmail.com wrote: I am reading Fossil File Formats at http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki where it says (section on Control Artifacts): When two or more tags with the same name are applied to the same artifact, the tag with the latest (most recent) date is used. Most recent date according to what clock? Fossil is distributed and clocks on different machines can be out of sync with each other so are artifact's timestamps. Can it cause problems? Am I missing something? Internally fossil uses a mix of Unix timestamps and (mostly, AFAIK) Julian dates. Unix timestamps are GMT/UTC and Julian is, as far as i'm aware, also timezone-independent. (Maybe someone better-versed in time handling can correct my Julian understanding.) http://en.wikipedia.org/wiki/Julian_day Commits/changes are performed on the client (then synched to the server), which implies that the timestamps are local and that a clock drift on a local machine will result in funky data on the server. (But again, perhaps someone here can correct that assumption.) -- - 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] documentation clarification
On Tue, Jan 31, 2012 at 10:42 PM, Leo Razoumov slonik...@gmail.com wrote: Hi List, I am reading Fossil File Formats at http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki where it says (section on Control Artifacts): When two or more tags with the same name are applied to the same artifact, the tag with the latest (most recent) date is used. Most recent date according to what clock? Fossil is distributed and clocks on different machines can be out of sync with each other so are artifact's timestamps. Can it cause problems? Am I missing something? The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. --Leo-- ___ 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] documentation clarification
On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. --Leo-- ___ 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] documentation clarification
On Wed, Feb 1, 2012 at 9:03 AM, Leo Razoumov slonik...@gmail.com wrote: On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. Just to be clear, Fossil does not use timestamps in constructing its DAG either. If the timestamps are off, then the graph looks a little weird (ex: http://www.sqlite.org/src/timeline?c=2010-09-29nd) but everything still works. But for some things, like tags, that do not have a parent/child relationship, timestamps are necessary for ordering events. If your system clock is off, you would do well to activate an NTP daemon on your machine. Fossil itself has no difficulty working with misconfigured system clocks, but the resulting project history becomes more difficult for humans to follow. Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. --Leo-- -- 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] documentation clarification
On Wed, 2012-02-01 at 09:03 -0500, Leo Razoumov wrote: On Wed, Feb 1, 2012 at 07:08, Richard Hipp d...@sqlite.org wrote: The clock according to the D card of the artifact. In other words, you can keep changing the value of a tag and the latest version always wins. If two people change the value of a tag while disconnected, then later sync, the latest change wins. Let say, the clock on your client machine is accurate but on my machine the clock is one year behind (slight exaggeration-:). You set a tag a month ago and I changed it today and then we sync. Your tag still wins because my clock is hopelessly behind! The problem is that D card value is set at the disconnected clients and there are no guarantee that all these clocks are synchronized. Generally speaking, one cannot rely on uncoordinated clocks to establish sequence of events. I think that was one of the reasons git does not use timestamps while building its DAG. Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. --Leo-- The wonders of the internet include the Network Time Protocol (http://www.ntp.org/) and I think all major operating systems have a mechanism for enabling it, if that is not the default. It is then possible to have synchronised time keeping to a meaningful level of precision. I can't speak for MS-Windows or MacOS but Ubuntu Linux uses NTP by default. ___ 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] documentation clarification
On Wed, 01 Feb 2012 10:18:18 -0400 Chris Peachment ch...@ononbb.com wrote: [...] The wonders of the internet include the Network Time Protocol (http://www.ntp.org/) and I think all major operating systems have a mechanism for enabling it, if that is not the default. It is then possible to have synchronised time keeping to a meaningful level of precision. I can't speak for MS-Windows or MacOS but Ubuntu Linux uses NTP by default. Windows (at least, since Windows XP) has native NTP client which one just have to set up more sensibly. For instance, [1] appears to be a quite sensible guide. 1. http://www.cumps.be/nl/blog/read/howto-set-up-ntp-on-windows-vista ___ 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] documentation clarification
Leo Razoumov wrote: Hopefully, this issue is of no practical importance, for one can always correct errors later on by pushing yet another tag. As with cryptography, keeping your clock up to date is essentiel... -- urban jc...@i2pmail.org http://chiselapp.com/user/jcage/repository/rdk/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] documentation clarification
Hi List, I am reading Fossil File Formats at http://fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki where it says (section on Control Artifacts): When two or more tags with the same name are applied to the same artifact, the tag with the latest (most recent) date is used. Most recent date according to what clock? Fossil is distributed and clocks on different machines can be out of sync with each other so are artifact's timestamps. Can it cause problems? Am I missing something? --Leo-- ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
