Unfortunately I've already fixed it using pre-filtering of the export
with repaired output, so my export-marks are correct now, and I'll be
unable to reproduce it anymore with my original tcl-repositories.
I can try to use empty export-marks, but fossil will create ca. 10GB
stream, and because of the another sequence it could rebase the whole
tree for git (because probably creates another SHA-ID's) so I could then
wait several hours to get an error (or success) in git...
... But if I take a look to the commit [1]...
Why it should be so complex (with interim temp-table "toponode", etc.)?
I cannot understand the necessity of this handling.
IMHO, if the result gets sorted by "rowid" (resp. "objid" of the
event-table), then it will bring the correct sequence equally.
At least it looks good if I try it with tcl-fossil-repo as database:
$ sqlite3 file:/core.tcl.fossil?mode=ro
-- ORIGINAL STATEMENT (FILTERED BY DATE AND BIT MANIPULATED FOR BETTER
READABILITY):
sqlite> SELECT datetime(mtime), objid,
quote(substr(coalesce(ecomment,comment),0,50)),
...> coalesce(euser,user),
...> (SELECT value FROM tagxref WHERE rid=objid AND tagid=8)
...> FROM event
...> WHERE type='ci' and date(mtime) BETWEEN date('2018-04-23') and
date('2018-04-25')
...> ORDER BY MTIME ASC limit 100;
...
2018-04-23 23:44:00|160883|'Merge 8.7'|jan.nijtmans|mistake
2018-04-24 13:12:46|160902|'merge 8.7'|dgp|mistake
2018-04-24 13:17:44|160851|'Empty checkin to try to isolate timestamp
damage '|dgp|mistake
2018-04-24 13:18:30|160922|'merge 8.7'|dgp|mistake
...
2018-04-24 23:32:00|160880|'Merge 8.6 (bug-fix and test-case for
Tcl_UtfAtInd'|jan.nijtmans|mistake
...
sqlite>
-- SAME STATEMENT ORDERED BY "ROWID":
sqlite> SELECT datetime(mtime), objid,
quote(substr(coalesce(ecomment,comment),0,50)),
...> coalesce(euser,user),
...> (SELECT value FROM tagxref WHERE rid=objid AND tagid=8)
...> FROM event
...> WHERE type='ci' and date(mtime) BETWEEN date('2018-04-23') and
date('2018-04-25')
...> ORDER BY ROWID ASC limit 100;
...
2018-04-24 13:17:44|160851|'Empty checkin to try to isolate timestamp
damage '|dgp|mistake
...
2018-04-24 23:32:00|160880|'Merge 8.6 (bug-fix and test-case for
Tcl_UtfAtInd'|jan.nijtmans|mistake
2018-04-23 23:44:00|160883|'Merge 8.7'|jan.nijtmans|mistake
...
2018-04-24 13:12:46|160902|'merge 8.7'|dgp|mistake
...
2018-04-24 13:18:30|160922|'merge 8.7'|dgp|mistake
...
sqlite>
Can you really imagine a pair "pid/cid" of the plink table, which can
contain the "invalid" sequence corresponding "objid" of the event table?
I mean as regards the child with objid greater as the parent?
I think, it is not really possible, also if some artifacts will be
manipulated using "purge" or similar logic.
Or I'm wrong?
BTW. I found an old ticket in your repository for the same topic:
https://www.fossil-scm.org/fossil/tktview/4013b0a81a66de9f7b59 [6]
Regards,
Sergey.
Am 04.05.2018 17:43, schrieb Richard Hipp:
> There is now a new Fossil check-in which might fix this problem. See
> https://www.fossil-scm.org/fossil/info/c0a3e9ff6fbe3b48 [1] for details.
>
> This check-in occurs *after* the version 2.6 release of Fossil. So
> you will need to recompile Fossil yourself in order to get access to
> this potential fix. Let me know if you need help in doing that.
>
> Sergey: Please try out the new Fossil and tell me "yes" or "no"
> whether this fixes your problem.
>
> On 5/3/18, Dipl. Ing. Sergey G. Brester <seb...@users.sourceforge.net> wrote:
> Hello Richard and all. 1. I assume it affects only import/export with options
> "--import-marks/--export-marks"... 2. Therefore I think, that the export of
> Andreas was never affected by this mistake, because he does whole (not
> partial) export (so without marks). 3. I cannot confirm the mentioned commit
> of Jan changes something (if options "--import-marks/--export-marks" used).
> In contrary I'm sure it still does not work, because I made my latest
> test-export on 02 May 2018, where Jan's commit was already pushed to tcl-repo
> (and the export still failed). 4. The idea to change order by clause (e. g.
> sort by rowid and not by date) sounds plausible (and I believe ordering by
> any date is wrong, at least by the usage of option "--git"). Regards, Sergey.
> 03.05.2018 19:55, Richard Hipp wrote: Fossil does its export in timestamp
> order. (Key source line here:
> https://www.fossil-scm.org/fossil/artifact/20d1516bc?ln=611 [2] [1 [2]]) But
> Jan did a check-in with a bad timestamp. (See
https://core.tcl.tk/tcl/timeline?unhide=on&n=25&y=ci&c=567e61b329c6b6f7872f [3]
[2]) That caused the MARKs to occur out-of-order. Jan subsequently fixed the
timestamp on the check-in (see https://core.tcl.tk/tcl/info/a0ad546f77dfc5a2
[4] [3 [4]]) so the export should be working now. Andreas - please confirm that
the export has been working ever since Jan fixed the timestamp on 2018-04-25. I
suppose a proper fix would be to change the ORDER BY clause to cause the
check-ins to be scanned in a dependency order, rather than in chronological
order. I'm not sure exactly what that SQL would be, though.... Links: ------
[1] https://www.fossil-scm.org/fossil/artifact/20d1516bc?ln=611 [2] [2]
https://core.tcl.tk/tcl/timeline?unhide=on&n=25&y=ci&c=567e61b329c6b6f7872f
[5] [3] https://core.tcl.tk/tcl/info/a0ad546f77dfc5a2 [4]
Links:
------
[1] https://www.fossil-scm.org/fossil/info/c0a3e9ff6fbe3b48
[2] https://www.fossil-scm.org/fossil/artifact/20d1516bc?ln=611
[3]
https://core.tcl.tk/tcl/timeline?unhide=on&n=25&y=ci&c=567e61b329c6b6f7872f
[4] https://core.tcl.tk/tcl/info/a0ad546f77dfc5a2
[5]
https://core.tcl.tk/tcl/timeline?unhide=on&amp;n=25&amp;y=ci&amp;c=567e61b329c6b6f7872f
[6] https://www.fossil-scm.org/fossil/tktview/4013b0a81a66de9f7b59
_______________________________________________
fossil-dev mailing list
fossil-dev@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/fossil-dev
