Ticket UUID: | a0756511991399b41255256111e03ebfe3e73a4d | ||
Title: | Fossil completely screws up repositories if there's any clock skew | ||
Status: | Fixed | Type: | Code_Defect |
Severity: | Critical | Priority: | |
Subsystem: | Resolution: | Fixed | |
Last Modified: | 2010-08-29 01:56:13 | ||
Version Found In: | all of them | ||
Description & Comments: | |||
This has resulted in a major frustrating hour. If anyone does a fossil clone when they have their clock skewed, they don't find out about it until they commit eventually and get:
fossil: ancestor check-in [4f205c7175] (2010-08-25 21:09:30) is younger (clock skew?) It happens because fossil clone doesn't enforce clock correctness. None of the commands except for commit do. So this is the pattern of complete fail:
I consider this a huge block to contributors. People will have their clock skewed. Tough. If it's so important than fossil should require it on clone, actually on any command that could screw up the timeline's clock and put someone into this totally screwed up state. drh added on 2010-08-28 20:14:35:
If the problem is (1), then all you have to do is fix the clock on your local machine. If the problem is (2), then simply run "fossil ui", browse to the previous check-in, click on the "Edit" link, and change the check-in time; (If multiple check-ins have been made using a bad clock, you might want to go back and fix up several prior check-in times.) I think this is a very sensible approach. What would you prefer Fossil do? Check-in the change out-of-order and let the poor user try to figure out what happened later? (That seems scary to me.) Or automatically adjust the timestamps? (That seems even scarier.) If you know of a better solution, please offer a suggestion. drh added on 2010-08-29 00:22:27: anonymous added on 2010-08-29 01:56:13: |