Fossil SCM

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:

1. Do a clone with your clock skewed.
2. Do some stuff, work really hard on something.
3. Add all these files you so lovingly crafted.
4. Try to commit your files. Oops clock skewed.
5. Fix your clock, nope timeline still says original time from the clone.
6. Try to reclone, nope you can't undo your adds so it bitches that you can't close.
7. Finally, copy your .fossil out of the way, copy your source out of the way, clone again, open again, and FINALLY you can start working again.

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 you get the message "ancester check-in ... is younger" then one of two things is wrong:

1. The previous check-in was correct but your current clock is wrong.

2. The previous check-in contains a bad timestamp

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:
Modified so that the "-f" open to "commit" will override the clock skew check and allow the check-in to proceed. It will then be up to an adminstrator to straighten out the check-in times using the check-in editor.

anonymous added on 2010-08-29 01:56:13:
Another option is to obey the principle of least surprise: if clock skew is a problem, upon any operation have Fossil do a sanity check on the time to warn of potential lurking skew problems before you've gone too far down the work line.