Hmm, another look reveals some surprises:
The "future" parent commit
(https://www.sqlite.org/src/info/655991ec8a781d67) also has a "date"
tag added, apparently in attempt to rectify the timeline:
date=2010-09-28 19:16:47 added by [5fd7e19e] on 2010-09-28 19:19:21
Similar situation is with the other "future" commit I mentioned.
Is this some undocumented Fossil feature which is supposed to allow
overriding of the commit timestamp?
Nevertheless, in either case the date tag values are ignored in the
timeline for both commits; the original timestamp is being used.
If date tag is indeed a way to tune the timeline, perhaps this should
be factored in both the timeline output and the selection of export
recordset.
On Thu, Feb 16, 2017 at 4:54 PM, Artur Shepilko <nomadb...@gmail.com> wrote:
> Indeed, in export.c the commits are lined up chronologically.
>
> There's a way to try to catch such inconsistencies by tracking when
> the "from :mark" gets freshly incremented (that is the parent has not
> been exported yet):
> src/export.c::~581
> int next_mark = unused_mark;
> zMark = mark_name_from_rid(pid, &unused_mark);
> if ( unused_mark == next_mark+1 ){
> /* Handle a "future" parent commit */
> }
> printf("from %s\n", zMark);
>
> Still, this will need a restructuring of the export flow.
> This may also become a run-away problem, once we start chasing the
> parent commit-chain through potential merges etc.
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
