Fossil SCM
localtime on server not syncronized. "strange" behaviour in fossil
683457aa0f15fad…
· opened 15 years, 11 months ago
- Type
- Feature_Request
- Priority
- Low
- Severity
- Minor
- Resolution
- Open
- Subsystem
- —
- Created
- April 20, 2010 4:49 p.m.
Hi. let me first say that fossil is a great tool witch is fun to use, and it really helps me with my workflow.
While playing with fossil on my eee i could not understand why my wiki edits did now show.
I was able to create new wikipages, but not able to edit old ones.
After a short while i finally noticed that the clock on my system was completly wrong because my eee had been off so long that BIOS clock was reset to year 2002(!)
I wonder if unsynced clocks might create similar or other issues for normal use, and if this problem could be solved in any way.
If the local fossil server creates artifacts with timestamp in the past, it could be useful with a warning.
It could be other way of dealing with this, and there is also a posibility to reject this ticket and expect people to have good clocks and ntpservices on their computers. - if so, maby some lines about this in the documentations.
Thank for a great tool.
Kjell.
Norway.
Comments (2)
Bumped into this with the following scenario:
# Commit to a fossil repository in a machine with the correct time setup. # Run a fossil server off a repository in a USB drive on the machine. # Sync the local repository with the USB repository. # Stick the USB drive into a new machine with a time setup that puts it in the past (in my case, it was an earlier timezone). # Run the fossil server off the USB drive in the new machine. # Sync a local fossil repository in the new machine with the USB fossil server. The local fossil repository will receive the artifacts from the "future". # "fossil update" the local repository. It will not retrieve the file contents from the "future".
As the original reporter commented, the least intrusive fix here would be to warn of strange timestamps during a sync or a pull. That should clue the user in to check the time settings. Once those are fixed, things work fine.
The trick here is how do you know what a "sane" time value is, if the local clock is desynchronized?
The best idea I've got at the moment is that the Fossil configure script can look at time stamps or fossil stat info to find the newest timestamp on any file in the source tree, then consider that a minimum sane date for new content.
In production, this will put a floor on sanity down in the weeks to months range, so it would catch the 2002 problem brought up above, but it won't catch a problem where one client is only minutes to hours off of correct.
We've got to be somewhat careful here. For instance, if I turn off autosync while I'm off on a 2-week vacation, then make a few checkins on my portable machine while my relatives go do unimaginably weird things like visit the beach instead of write new software, when I return to work and sync my changes up, the server is going to see checkins up to 2 weeks old. The server must not reject those simply because they were created "in the past."
In a DVCS, there's a limit on how strict the central server can be. If we cannot trust time sync in 2018, a whole lot of other things break, too. make breaks, for instance.