While I am a fan of chains of small cooperating tools, there is something to be said for a single large tool with a well-integrated feature set. Here are some

While I am a fan of chains of small cooperating tools, there is something to be said for a single large tool with a well-integrated feature set. Here are some of the advantages you get when the code repo, bug tracker, and wiki are all part of the same coherent system: 1. When a checkin fixes a bug noted in the ticket tracker, you can reference it in the checkin comment with a subset of the ticket ID: "Fixes [3b52b91fc]" That ticket ID becomes clickable in the web view of the timeline, taking you directly to the referenced ticket. Yes, I know, this is not a unique feature, but the other systems that have this also integrate the ticket tracker and code repo. The point is that you get this feature out of the box with Fossil, for free. 2. Your next step is to close the bug ticket. This modifies the appearance of the checkin comment you created in the previous step in the Fossil UI timeline view, rendering the ticket ID as strikethrough text, so you can see it refers to a closed ticket without clicking on it. The key point here is that the integration is bidirectional. (It would be even neater if Fossil would recognize the pattern "Fixes [artifact-ID]" in checkin comments and automatically close the ticket for you. It shouldn't be too difficult to add, since it's a unified system.) 3. Anywhere that Fossil accepts regular URLs, it will also accept artifact IDs. So, you can refer to checkins or tickets from the wiki, or from within a Markdown document checked into the code repo. 4. Because Fossil understands Markdown as one of its available wiki article formats, it can render Markdown documents in the code repo inside the Fossil UI when you click on them from the Files tab in the web UI. 5. That feature extends to other document types, too. This leads to the embedded documentation feature (http://fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki http://fossil-scm.org/xfer/doc/trunk/www/embeddeddoc.wiki) which is a versioned alternative to the wiki. You use the wiki for articles that apply to all versions of the repository, or at least to the current trunk version. Where you instead need a given doc article to roll back to its historical content when you roll back the code, you want to use embedded documentation instead. You can use the wiki and embedded docs interchangeably, linking from one to the other, as needed.