Hacker News Reader

Comment by cytzol | Hacker News Reader

> 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?

View on HN

No, unfortunately. How is this different to and / or better than having a "wiki/" subfolder, and, e.g. an Org-mode file (need not be org-mode, even a plain text file is o.k., and there are wiki systems and todo managers that use plain text) for issues on the project root? I can easily "git/hg/cvs log project.org" to see the history. And the format is not tied to the VCS software, so, if I switch to sth. else, it's still perfectly usable.

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]

Ah, I see. In that case, you're right, it's not: if you track issues and docs like like in the same way as you track source files, then functionality-wise they're no different.

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.

Reply on news.ycombinator.com