Fossil Forum

no repolist page and assert on console while browsing repolist URL
Login

no repolist page and assert on console while browsing repolist URL

no repolist page and assert on console while browsing repolist URL

(1) By PF (peter) on 2022-02-02 20:49:09 [link] [source]

Since this evening I am unable to show repolist page with command I use for more that a year. All I get is "The connection was reset" in the browser (firefox 96) and the:

fossil: ./src/repolist.c:211: repo_list_page: Assertion(rNow - x.rMTime)<=(((unsigned)~0)>>1)/86400.0' failed.`

message on console.

If I get URL to individual repos, I can see them just fine. The whole problem seems to be related to repolist page. I am on xubuntu v 20.04 I was using fossil based on check-in: 0505bc8289

I have checked with downloaded stock version of fossil (2.18 [57f16ce8e5] 2022-01-27 11:20:09 UTC) with the same results.

BUT downloaded fossil 2.17 [f48180f2ff] 2021-10-09 14:43:10 UTC shows repolist page/individual repos just fine.

My fossil server line is:

fossil server -P 8089 --localauth --extroot /home/usr/repos/myext --user usr --repolist --files \* /home/usr/repos/. &

Can anyone confirm?

Thanks, Peter

(2) By Martin Gagnon (mgagnon) on 2022-02-02 21:56:17 in reply to 1 [link] [source]

works for me on on Ubuntu 18.04 with fossil version:

This is fossil version 2.18 [0505bc8289] 2022-02-01 13:20:40 UTC

Like you, I also tried with 2.18 [57f16ce8e5] 2022-01-27 11:20:09 UTC from fossil download page (x86_64).

my server command:

fossil server -P 8089 --localauth --extroot ~/Documents --user ndt --repolist --files \* ~/fsl_repo/. &

I guess there's something different on your setup.

(3.1) By Daniel Dumitriu (danield) on 2022-02-02 22:29:12 edited from 3.0 in reply to 2 [link] [source]

It works for me, too.

There must be something peculiar with one of the repositories in that directory. The failing assert (introduced by Richard last Thursday) involves a repository's last modification time (more precisely, timestamp of the latest event).

We need more information for further analysis. For example, what does fossil sql "SELECT max(mtime) FROM event" -R <REPOPATH> say for those repos?

Edit: you can try to (re)move the repos one by one to find the culprit.

(4) By Richard Hipp (drh) on 2022-02-02 23:40:15 in reply to 3.1 [link] [source]

I just merged the change to trunk. I didn’t add it.

(5) By PF (peter) on 2022-02-03 06:08:44 in reply to 4 [link] [source]

With fossil based on check-in: https://fossil-scm.org/home/info/537a1394d8cfd342 repolist works fine for me again.

Thank you for fix.

(6) By Daniel Dumitriu (danield) on 2022-02-03 07:22:09 in reply to 4 [link] [source]

You are of course right, it was Larry's change. I had just looked at the blame output.

Which reminds me of an older idea: Should we give the opportunity for blame, annotate and the reports (through a flag resp. checkbox) to skip the merge checkins, i. e. for any such checkin, consider the first (non-merge) parent?

(7) By PF (peter) on 2022-02-03 19:55:17 in reply to 3.1 [source]

what does fossil sql "SELECT max(mtime) FROM event" -R <REPOPATH> say for those repos?

Good question. There were some repos from my abandoned experiments with empty repositories without initial empty check-in (build by fossil reconstruct route). There is NULL in event.mtime.

fossil sql "SELECT max(mtime) FROM event" -R ./manned.empty.fossil 
NULL

fossil sql "SELECT max(mtime) FROM event" -R ./manned.fossil 
2459590.2952430560254

Fixed repolist page now hapilly reports Last Modified time as 6734.20 years for an empty repo.

(8) By Daniel Dumitriu (danield) on 2022-02-04 11:37:09 in reply to 7 [link] [source]

With the latest trunk as of now, it should report "unknown" for "Last Modified" in such cases.

Or should it perhaps say "no event" or similar?

(9) By Larry Brasfield (larrybr) on 2022-02-04 18:55:30 in reply to 8 [link] [source]

"unknown" is better, I think. "no event" may be more meaningful to insiders, but is likely to induce needless puzzlement and/or consternation for other users.