On 2/16/2017 1:11 PM, Artur Shepilko wrote:
....
This fix seems to allow the git fast-import to proceed past this ...
until it finds another inconsistency, unrelated to the one above. This
time it's with commit:
https://www.sqlite.org/src/info/3f30f00a384d2358
Again, looking at the timeline
https://www.sqlite.org/src/timeline?r=trunk&d=2010-09-28
There's a unusual timeline zig-zag on 2010-09-29, where a "future"
commit (https://www.sqlite.org/src/info/655991ec8a781d67) is a parent
to a "past" commit above. Apparently, there was some time skew which
crept in.
Same happened with the another subsequent "future" commit
(https://www.sqlite.org/src/info/1ef0dc9328f47506, parent to "past"
https://www.sqlite.org/src/info/f34dc54d46d05adf) .
The timestamps for these "future" parent commits are supposed to be
prior to timestamps of their children commits.
Not sure what's a right way to fix the skewed timestamps, no handy
command for this. Prehaps through "fossil sqlite3" direct surgery,
but one needs to know how not to kill the patient in the process...
Fossil hid some skeletons in the Sqlite's closet, Git just found some.
Let's bring them to life :)
I'd argue the problem here is with Git.
Sure, we'd all love it if everyone kept their clocks in sync, but in the
real world skew is simply going to happen. In the absence of a central
server to provide the authoritative time stamp, a DVCS like both Fossil
and Git has no real choice other than to trust the time provided by each
local machine as authoritative enough to document each commit.
If commits from each user of a project end up lined up in order on the
timeline, that is just a happy side effect of people keeping their
clocks synchronized.
Having a parent committed after a child does look odd, but I think it
has to be simply accepted as part of the record, warts and all, of the
work on the project.
I know that Git users like to be able to polish those warts off.
Fossil doesn't care. And shouldn't care.
The timestamp of each checkin is stored in the D card of the checkin's
manifest, so it is not possible to edit it directly without changing the
SHA1 hash of the checkin.
--
Ross Berteig r...@cheshireeng.com
Cheshire Engineering Corp. http://www.CheshireEng.com/
+1 626 303 1602
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
