Fossil version 2.25 came out a little over four months ago on 2024-11-06. Changes since then (as I write these words):

• 389 check-ins on paths between the 2.25 release and the latest trunk. The graph.
• 125 files modified, with 15699 insertions and 8130 deletions.
• Perhaps the biggest change log that we've ever had.

It is customary to do Fossil releases shortly follow after SQLite releases, so that the SQLite built into Fossil is of the latest release. But right now, we are mid-cycle for SQLite, and the SQLite running in Fossil at the moment is labeled as 3.50.0 2025-02-15. I don't want to "downgrade" to SQLite 3.49.0. Even so, I'd like to do a new Fossil release soon.

Who would object to that?

No objections from me. Nice job to all the developers.

Couple curiosity questions...

389 check-ins on paths between the 2.25 release and the latest trunk.

The version-2.25 page takes you here: https://fossil-scm.org/home/info/name=version-2.25 and displays No such object: name_version-2.25
Is that expected?

125 files modified, with 15699 insertions and 8130 deletions.

How'd you calculate that?

The graph.

When i click that link to open in a new tab, i can see the graph, but if I copy the link and paste into a new tab, it wants me to login.
How'd you bypass the robot test?

https://fossil-scm.org/home/info/name=version-2.25 and displays No such object: name_version-2.25 Is that expected?

Where are you seeing that link? It's missing a "?" before the name. Try either of:

• https://fossil-scm.org/home/info/version-2.25
• https://fossil-scm.org/home/info?name=version-2.25 (is equivalent: fossil internally assigns everything after info/ to the "name" URI parameter)

I had the same question, Stephan. Then Daniel checked in the fix and I immediately understood. :-)

Perhaps the biggest change log that we've ever had.

Could be also containing the mention of the new ability to attach special wikis to tickets.

Which brings me to the question: what is customary in adding to the changelog? Should I change it on the branch so it is merged with the feature? Or will it be added when the branch is merged to trunk?

Could be also containing the mention of the new ability to attach special wikis to tickets.

i thought i had added that to the change log when merging that branch, but apparently neglected to. When attempting to do so a moment ago i wasn't happy with my description, so will ask you to please add an appropriate entry to www/changes.wiki.

i wasn't happy with my description

Dunno if you like mine better, but there it is.

I hadn't had cloned fossil yet on this laptop, so the Hotel WLAN got to real good use suddenly.

I've noticed the check-in to remove markup from comments printed to the CLI has quite some side-effects.

For example, it seems to change the location where line-breaks are inserted (that is, it affects line length calculation) for some comments that don't contain any markup at all.

Command for my tests:

fossil timeline --limit=0 --width=N

I've run this with the full Fossil history, with different values for N, and then compared the results with and without the referenced check-in.

I've just had a very limited amount of time for this, so far, and I couldn't find anything destructive at first glance, but I'd like to do more investigations, at least to understand what's going on.

Maybe it's worth to give the new comment mangling some time for field testing before the next release?

OK, now I think I know what's going on (or at least in this specific case):

Test without [6ab9994de6]:

C:\...> mode con

Status for device CON:
----------------------
    Lines:          69
    Columns:        97
    Keyboard rate:  31
    Keyboard delay: 1
    Code page:      437

C:\...> fossil timeline --comment-format=1 --limit=1 a91586d256 & REM: without [6ab9994de6]
=== 2025-03-08 ===
23:58:44 [a91586d256] Restore the "shortest" query parameter on /timeline. Make it actually
         show the path with the fewest number of nodes, as it was originally intended. Improve
         the /help for /timeline. (user: drh tags: min-from-to)
--- entry limit (1) reached ---

Test with [6ab9994de6]:

C:\...> mode con

Status for device CON:
----------------------
    Lines:          69
    Columns:        97
    Keyboard rate:  31
    Keyboard delay: 1
    Code page:      437

C:\...> fossil timeline --comment-format=1 --limit=1 a91586d256 & REM: with [6ab9994de6]
=== 2025-03-08 ===
23:58:44 [a91586d256] Restore the "shortest" query parameter on /timeline. Make it actually show
         the path with the fewest number of nodes, as it was originally intended. Improve the
         /help for /timeline. (user: drh tags: min-from-to)
--- entry limit (1) reached ---

The comment of [6ab9994de6] as stored in the check-in manifest:

C:\...> fossil artifact a91586d256
C Restore\sthe\s"shortest"\squery\sparameter\son\s/timeline.\s\sMake\sit\sactually\sshow\nthe\spath\swith\sthe\sfewest\snumber\sof\snodes,\sas\sit\swas\soriginally\sintended.\nImprove\sthe\s/help\sfor\s/timeline.
...

It looks like the comment formatter takes into account double-spaces (\s\s), and the new logic to mangle comments wipes them out. From my few tested samples, it seems they are all related to double-spaces, so this issue should be harmless.

I always assumed double-spaces were eliminated before saving comments in the check-in manifest, along with leading and trailing spaces, but obviously I was wrong. Maybe double-spaces are required to use any meaningful block markup in comments.

I'm now the human replacement for comment.test ... ;-)

the new logic to mangle comments wipes [double-spaces] out.

Specifically, it used to show the comment as originally entered by the user, spaces and all. It has now been changed to:

1. Format the comment as HTML for display in a browser. (procedure: wiki_convert())
2. Convert the HTML into plain-text by removing all of the HTML markup. (procedure: html_to_plaintext()).

This two-step process makes the output of the TTY timeline look must more like the output from the HTML timeline. Surplus whitespace is removed during step 1.

When your message arrived in my (text format) email I notice that the spacing before the parenthesis in each step is different. In step 1 there are two spaces after the period, in step 2 only one. I presume that this means the extra space must have been included in the original.

Test: One. Space. Two. Space.

In the HTML version the spacing looks regular, but if you dig out your vernier caliper you will discover the space after any period is slightly thicker. This is a combination of the HTML engine and font rendering.

I first learned to type on a mechanical typewriter, and got into the habit of putting two spaces between sentences e.g. after the period at the end.

With my OCD hat on I suggest that maybe these double spaces are not 'surplus', and should not be reduced in step 1. It would make no difference to the rendering of the HTML as the HTML parser does its own thing with whitespace anyway.

On a different day I may well think it isn't worth bothering with, knowing from experience how hard it is to cover all the cracks between typesetting and plain text.

Trevor

Putting two spaces after a sentence is a style that is often seen in source code comments (also in Fossil), man pages, readme files, and also in a lot of (source texts of) posts to this forum.

When I work on text with this style, I try to preserve it. But often when I reflow plain text paragraphs, I drop it, because my preferred text editor doesn't support it.

When I see this in plain text, I always assume that the author is a programmer with decades of experience (when not so many styling options were available), and I always think that the author is a careful person paying attention to details, so I tend to take this formatting as some sort of quality seal. (Disclaimer: I'm not using it, myself.)

Whether or not it really improves readability of plain text, I'm not sure. Maybe not that much that I would miss it.

Not sure if it's worth to hack the markdown → HTML → plain text conversion to preserve this style, as this may add a lot of complexity and possibly new bugs.

As far as I know, the double space after the period ending a sentence is an American habit, rarely observed in Europe. The difference extends to typesetting, where US typesetters often put a wider space after a sentence (compared to the usual interword space). For those familiar with TeX, there is an command \frenchspacing which will make a space after a period the same width as an interword space. The default is to make it somewhat longer.

Anecdote: Back in the early 1980s, I had a credit card stolen while in Paris. I had to go to the police station to report it (credit card company requirement), and ended up with a copy of the report laboriously typed out by a French policeman whose English was barely any better than my French. He didn't put a space after period at all.Like this.A strange thing to behold.

Double spaces after sentences on typewriters was developed out of a limitation of the medium. In ye olde monospace days, it was not possible to have a properly-spaced deliminator between sentences, and two spaces became a norm as a compromise.

Emacs still uses the convention to denote sentence separations, in contrast to strings like "Mr. Hipp" that should not be separated by line breaks. If you use Alt-Q in Emacs to automatically reflow plain text, it'll work by the two-spaces-after-sentences convention.

It helps my clarity of thought to get some exercise during the working day too.

There is also a problem with .fossil-setting/manifest in that its value is not getting picked up by db_get_manifest_setting(), and consequently, if that file gets created and set to "on", the Git-export is incorrectly omitting the "manifest" and "manifest.uuid" files. See https://github.com/drhsqlite/pikchr/issues/6 for the bug report.

I need to chase this to ground before doing a release.

Instead of a new release, I uploaded new precompiled-binary snapshots of the latest code to the Download page so that anybody who wants all the latest features can get to them easily enough. We don't have to call that a "release".

I'll reconsider a release after things settle down after the recent flurry of enhancements.