Issue tracking and wikis are not a version control problem. Sure, their data can be version controlled. And documentation has been version controlled since Sccs, why would it require special care?
It doesn't, really, but it's in the same place as the code and everything else (this is what I meant as being "on the same level"). You don't need to clone the code and then clone the tickets, for instance. When you run "fossil timeline" on your local machine, you'll see entries for tickets being closed and wiki pages being updated interspersed among the actual code commits. This is useful to me as they're as much a part of the project as the code itself. Does this answer your question?
An basic example of an org file for tracking issues:
#+title: Project issue tracker
#+description: descr...
#+todo: OPEN(o!) | CLOSED (c@)
This is the issue tracker for Project. In order to add a
new issue, add it to the top of the entries as a plain org
entry, then hit =C-c C-t o= to mark it as open. In order
to close an issue, on it's headline, hit =C-c C-t C=,
this will prompt for a closing comment, see the buffer that
pops up for instructions.
Common tags: docs, features, bugs, security, ideas
* CLOSED Write README. :docs:bookkeeping:
- State "CLOSED" from "OPEN" [2016-03-22 Tue 02:16] \\
Written.
- State "OPEN" from [2016-03-18 Fri 22:33]
* OPEN Implement new features :features:
- State "OPEN" from [2016-01-27 Çrş 23:35]The differences that remain are purely in the interface. For example, although they're synced the same way, VCSes tend to display issues differently than source; it's easier to filter out issue changes from the timeline, and harder to accidentally delete other people’s comments. It also makes it possible for people who aren't actual members of your project to raise and comment on the issues, which wouldn't usually be possible (unless your VCS can manage permissions for each file).
One particular use case of yours that Fossil does support is the ability to have a "wiki/" subfolder and have the web interface automatically format and display the pages inside, so you can link to them more easily if you're using the HTTP server for hosting. I think I use this feature more than the built-in wiki because it’s possible to version the docs along with the source, ensuring they never go out of sync.