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-29&nd) 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
