Fossil SCM

This comes from further investigating of the problem quite bad reported at [f1c75f3844687].

I got confused again when I said it was about time (I missed one unsynched local 'fossil ui' with the server).

So, as said, you can clone that repository: http://vicerveza.homeunix.net/~viric/cgi-bin/nanonixos You will see in the timeline of the server that the event related to the artifact 4d12cabdeca86a71190c39b1e458faae4fad0faf does not appear in the timeline. But I imagine it will appear in your local fossil timeline.

I've investigated a bit...

That server (vicerveza.homeunix.net) running fossil as a cgi is an armv5tel-linux. I tried there fossil [cf178577ec] 2010-11-17 and fossil [12a79e5b93] 2010-10-05). Both show the same behaviour: the event of that artifact is not shown in the timeline. I've tried in all the cases a 'rebuild'.

Nevertheless, if I clone that in an x86_64-linux, I don't have any problem in the local 'fossil ui', using the [cf178577ec] 2010-11-17 version.

The server, to give more details, has gcc 4.5.1, glibc 2.12.1, and all fossil tests passed after building.

anonymous claiming to be viric added on 2010-11-30 19:40:51: As long as investigate... I'm trying "fossil sqlite3". There should be three events, and for example I get:

sqlite> SELECT * from event WHERE event.type='e';
e|2455530.46353009|168|19||||viric||The malta keyboard does not work still|
e|2455530.49096065|169|20||||viric||links2 not working in graphics mode|

anonymous claiming to be viric added on 2010-11-30 20:06:55: I've just compared de "rebuild -quiet -sqltrace" both in x86_64 and armv5tel. The concerning block with the difference is:

282,283c285,288
< SELECT rid FROM tagxref WHERE tagid=11 AND mtime<2455525.422407407 ORDER BY mtime DESC;
< SELECT rid FROM tagxref WHERE tagid=11 AND mtime>2455525.422407407 ORDER BY mtime;
---
> SELECT rid FROM tagxref WHERE tagid=11 AND mtime<2455525.422407408 ORDER BY mtime DESC;
> DELETE FROM event WHERE type='e'   AND tagid=11   AND objid IN (SELECT rid FROM tagxref WHERE tagid=11);
> SELECT rid FROM tagxref WHERE tagid=11 AND mtime>2455525.422407408 ORDER BY mtime;
> REPLACE INTO event(type,mtime,objid,tagid,user,comment,bgcolor)VALUES('e',2455525.421157408,74,11,'viric','Nanonote boot',  (SELECT value FROM tagxref WHERE tagid=1 AND rid=74));

I think there may be a problem on floating point precision / algorithms. The armv5tel cpu does not have a FPU, and it uses gcc's -msoft-float.

anonymous claiming to be viric added on 2010-11-30 20:33:57: So, manifest_parse includes:

        p->rDate = db_double(0.0, "SELECT julianday(%Q)", next_token(&x,0));

While the tag_insert called in manifest_crosslink() does:

  db_prepare(&s,
    "REPLACE INTO tagxref(tagid,tagtype,srcId,origid,value,mtime,rid)"
    " VALUES(%d,%d,%d,%d,%Q,:mtime,%d)",
    tagid, tagtype, srcId, rid, zValue, rid
  );
  db_bind_double(&s, ":mtime", mtime);

While the call at manifest_crosslink() does:

    prior = db_int(0,
      "SELECT rid FROM tagxref"
      " WHERE tagid=%d AND mtime<%.17g"
      " ORDER BY mtime DESC",
      tagid, p->rDate
    );

I think that the %.17g printf kind of prompt should be moved into db_bind_double, as before. Otherwise there may be rounding problems, like those I am experiencing.

Notice that the tag_insert resulted, in both computers, in:

REPLACE INTO tagxref(tagid,tagtype,srcId,origid,value,mtime,rid) VALUES(11,1,74,74,'365',2455525.42240741,74);

While the printf-style SQL queries with %.17g had different results in the two computers.

anonymous claiming to be viric added on 2011-01-10 08:20:18 UTC: Is [722d7cac97] going to mean any improvement on this?

Thank you.

viriketo added on 2011-05-13 16:08:19 UTC: I think [9b26d1e9a2] may have fixed the problem. I'll try.