4 ms·
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 ar
by cakoose 12y ago
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.
- stephenr 12y agoMarking 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.
- sgbeal 12y agoSeparation of tickets and VCS: that has been a bit of a stickler in the development of libfossil (http://fossil.wanderinghorse.net/r/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).