El 09/08/2013 14:18, "Richard Hipp" <[email protected]> escribió: > > > > On Fri, Aug 9, 2013 at 7:40 AM, Isaac Jurado <[email protected]> wrote: >> >> As I understand it, in Fossil, the history is mostly driven by the date >> and time of the events, whereas in Git and Hg ancestry relationship >> comes first. I gues this is one of the reasons of why there typical >> "log" command is called "timeline" in Fossil; and also why hiding the >> possibility of altering the commit time, because it would lead to a >> confusing timeline graph. >> >> When I converted an Hg repo that had its history reordered (with "hg >> histedit"), the resulting Fossil timeline had an arrow pointing >> downwards which made it look a bit weird. > > > The timeline display in Fossil is date driven. But the underlying repository uses ancestry relationships, just like Git and Mercurial.
Sure, I didn't mean otherwise. What I was trying to explain is that when using Git or Mercurial one is under the impression that commit dates are just informative. However, Fossil's timeline pays more attention to dates. Of course, all systems properly record ancestry relationships. > When you have a parent that is younger than its child, we call that a "time-warp" and it results in a funky backwards arrow on the timeline display. See http://www.sqlite.org/src/timeline?c=3f30f00a384d&nd for an example. Timewarps can be caused, for example, when commits occur on a system were the system clock is set to the wrong time. > > When doing a sync, Fossil compares timestamps on the local and remote machines and issues a warning if they are misaligned. The whole point of that warning is to try to prevent timewarps. > > You can get a list of all timewarps in a project by visiting the /test_timewarps page in the web interface. There were several timewarps in the SQLite history (as seen at http://www.sqlite.org/src/test_timewarps) but most of them have been fixed by adding tags to check-ins that "correct" their check-in time. The http://www.sqlite.org/src/info/cbfe6e9df3check-in, for example, had an original check-in time of 2009-08-20 09:11:06 but this was adjusted to 2009-08-20 16:11:06 for display purposes using a tag, specifically the http://www.sqlite.org/src/info/14cc3387df tag. > > You could, in theory, generate timewarps in Git too, since each check-in has a timestamp, iirc. Does anybody know what would happen on the GitHub timeline graph for a Git repository that contains a timewarp? I can't speak for git, but in Mercurial when examinig the history graph the dates are secondary. Therefore, time warps are not highligthted and it's up to the user to check. Thanks for the other information.
_______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
