Fossil Forum

typo/dead link thread

typo/dead link thread

(1) By anonymous on 2021-11-28 12:45:03 [source]

Let me make a typo thread (because I am currently falling in love with Fossil and reading all its docs)

I will not repost typos already posted on other threads

here is another: dead link(s) in the footer of the page

(2.1) By KIT.james (kjames3411) on 2022-01-10 03:36:13 edited from 2.0 in reply to 1 [link] [source]

information about the makeheaders.html file is outdated in (& link is dead)

(file has moved from src/ to tools/. I guess that other docs might need some updates)

(4) By Stephan Beal (stephan) on 2022-01-10 05:18:45 in reply to 2.1 [link] [source]

(file has moved from src/ to tools/.

Fixed, thank you.

I guess that other docs might need some updates)

All of the ones grep turned up in www/ are now fixed, but if you find any others (e.g. in wiki pages, which we can't easily grep), please let us know.

(6) By KIT.james (kjames3411) on 2022-01-10 12:40:10 in reply to 4 [link] [source]

Ok thanks. By the way I think the distinction between wikis and docs in Fossil is quite hard to grasp (from a user point of view), although I still do not know enough to make good suggestions.

(8) By Stephan Beal (stephan) on 2022-01-11 00:29:48 in reply to 6 [link] [source]

By the way I think the distinction between wikis and docs in Fossil is quite hard to grasp...

In The Beginning, there was only Wiki, and Wiki was Good. Wiki has several limitations, though, namely that it does not partake in the branching and merging mechanisms. Every version of very wiki page is saved, but they're not "snapshotted" along with the rest of the source tree when a checkin is made. In that sense, wiki pages are in a different "namespace" than the SCM content which is stored as files.

"Embedded docs" arrived a couple/few years later and is essentially the marriage of the source tree's SCM mechanisms with wiki-style documentation, the fundamental difference from the wiki being that the docs exist in the filesystem alongside the rest of the SCM'd files.

In this particular project we tend to use embedded docs for almost everything, whereas the wiki tends to be used for a small handful of historical pages like a long-running TODO list and instructions for building release binaries of fossil. Those tendencies vary by project, though. For some, plain old wiki is perfectly adequate.

(9) By KIT.james (kjames3411) on 2022-01-11 12:14:46 in reply to 8 [link] [source]

Thank you very much for this info & lore :)

(10) By Warren Young (wyoung) on 2022-01-11 14:00:00 in reply to 9 [link] [source]

The simple rule of thumb I use is that if you have a document that needs to be versioned along with all the rest of the repo's content, you use embedded docs. If it has an independent lifetime and you always want to see the latest version, then use the wiki.

(11) By KIT.james (kjames3411) on 2022-01-12 13:05:38 in reply to 10 [link] [source]

Very simple indeed. Thank you. (So, would it be like some sort of unversioned file? I will be reading most of the source code soon, but..)

(12.2) By Warren Young (wyoung) on 2022-01-12 17:17:41 edited from 12.1 in reply to 11 [link] [source]

would it be like some sort of unversioned file

As Stephan said up-thread, wiki articles are versioned. What we're pointing out is that if you say

  $ fossil up 2020-03-01
  $ fossil ui

…you won't suddenly start seeing your wiki articles as rolled back to the start of the pandemic. The web UI will continue to show their latest versions by default.

You can click the History link above each article to dig into past versions, but if you then click a link from that historical wiki article to another, you'll go to the target article's current version, not to the one as of the source article's date.

Contrast embedded docs, where rolling back to an old version and using the "ckout" special name will let you see all the docs as of that date. Furthermore, giving a URL like /file/foo?name=bar will tack ?name=bar onto certain URLs embedded in the page, so you'll tend to stick within that "bar" version until you take a link that pops you out of that time capsule.

I will be reading most of the source code soon

Experienced C programmers will find the Fossil source code fairly clear, but for the purposes of this thread, I think you'll find that simply trying things with the built binary suffices.

(13) By KIT.james (kjames3411) on 2022-01-13 12:32:02 in reply to 12.2 [link] [source]

Thank you.

By the way the reason I'm reading the source code is because I fell in love with Fossil and want to know it more profoundly (sounds like what living beings would do.. ^^)

I might also make proposals and patches in the future, idk.

(14) By Stephan Beal (stephan) on 2022-01-13 13:10:42 in reply to 13 [link] [source]

By the way the reason I'm reading the source code is because I fell in love with Fossil and want to know it more profoundly...

That's how it starts, but beware: #TheAddictionIsReal

(15) By Marcelo Huerta (richieadler) on 2022-01-13 14:40:33 in reply to 14 [link] [source]

Tell me about it. I cannot go one day without checking if there are news and compiling my new local version of Fossil in my Windows machine.

I'm not such a maniac with the instance I have running for my Sourceforge clones, though :D

(16) By KIT.james (kjames3411) on 2022-01-16 05:35:10 in reply to 14 [link] [source]

I'm planning to use Fossil for my new infrastructure (and for a long time) so my addiction to this Forum will be real, be prepared!

(3) By sean (jungleboogie) on 2022-01-10 03:49:34 in reply to 1 [link] [source]

Might be better to make a patch file for the changes.

(5) By KIT.james (kjames3411) on 2022-01-10 12:35:06 in reply to 3 [link] [source]

This kind of fix is better made by people knowing the project because otherwise all of the other occurences have a higher chance of being ignored because "patched kthx bye"

(7) By KIT.james (kjames3411) on 2022-01-10 12:45:04 in reply to 5 [link] [source]

By the way I think if you say this kind of thing to everyone contributing in the end there will be less and less people contributing.

Isn't "some info" better than "no info"? :)