That last statement needs more justification. Tickets, in particular, are fundamentally tied to the code base. There are lots of things you could use the wiki for, like internal API documentation, that are just a step above in-code comments. Why on earth shouldn't they be stored in the same system with the code, especially when that arrangement simplifies the setup needed to start working on the project?

Code base !== One repo. I agree for some projects this all-in-one system might be beneficial, I'm saying personally I would expect teams to use standard tools for tasks. A wiki and ticket system that works the same regardless of the type of repo you use.

Im looking at this from the point of view of providing infrastructure for teams to work on different projects. A project does not necessarily mean a single repo.

Fossil's bug tracker is not just a separate system bundled with Fossil. The bug database is integrated with the VCS for a reason. Edits to the bug database are tracked, branched, and merged the same way source code is.

For example, let's say you create a branch to work on a new bug fix. In that branch, you make the fix to the source code, and modify the bug status to "fixed". When you merge your branch back into trunk, both the code fix and bug status get merged atomically.

It definitely is possible to create a bug tracker that did these things but was still separate from the VCS. I remember seeing some early-stage bug trackers that stored all bug data as files in the repository (instead of in a separate database) and could be made to work with multiple VCS backends easily. However, since VCSes weren't designed for this, it was sort of of clunky to use.

Ideally, there would be some interface between VCS and bug tracker to make sure they're decoupled but still work well together, but nobody has figured out that interface yet. Until someone does, it's much simpler for Fossil to ignore the coupling issue for now and focus instead on making the best product they can.

Separation of tickets and VCS: that has been a bit of a stickler in the development of libfossil (http://fossil.wanderinghorse.net/r/libfossil). In fossil the ticket system is married to a custom mini-script engine called TH1. In libfossil we want to avoid any specific script binding. That's turning out to be quite difficult, as Fossil's ticket system is built from the bottom up on top of TH1 (which is not a very flexible language).

Marking issues/tickets as closed based on commit messages in a configured VCS isn't exactly unheard of in regular stand-alone issue management systems you know.

> I would absolutely discourage the use of it's wiki and ticket systems, in favour of independent solutions that are not tied to the repo and repo software itself.

I'm interested what you think about BugsEverywhere ( http://bugseverywhere.org ), which keeps bug info in a hidden directory in the repo and integrates well with git. I've not used it before, but am considering it for a research project I've inherited which has no infrastructure (just source code in a zip file). I'd like to avoid proprietary hosting (eg. github) or hosting my own web server (eg. gitlab), so I'm thinking that BE would be a good fit, with hosting on gitorious.org

It looks interesting, and the multi-vcs support is quite good, and I guess in theory in a multi-repo project, you could just have a repo called "bugs" or "issues" if you wanted to keep that stuff separate.

The demo of the Web UI gave a 502 so I couldn't access it and I don't have time to try it out locally right now..

it looks like BugsEverywhere is in maintainance mode (if not dead already)