schwabrak -- simple flat file based issue tracker

Note: this is the second version/iteration/suggestion.
Look for previous one in older commits.

I want a relatively simple issue/ticket tracker. Something like Trac,
Redmine or Fossil. But they require heavy dependencies (Python, Ruby),
database and they are centralised. You can not work with them offline
and it is relatively complicated to replicate data to a locally running
copy of any of those trackers (well, except for Fossil I believe). And
is a web-interface necessary at all?

What is a ticket/issue? Just some plain text descriptions, with attached
enumerations (statuses, assignments, priorities, projects, subsystems,
severities, resolutions, etc) and a pile of append-only comments,
possibly with another file attachments. Can all of that live in a
directory with several plain text files? Do Git commits provide
supplementary metainformation about when and by whom any of the change
is made in that directory? Definitely yes! And because of DVCS you get
ability to keep the whole distributed copy of the tracker on each
developer's machine. You can send changes to it asynchronously as a
patch or bundle.

Basically schwabrak is mainly about a convention how to keep issues in
files, loosely similar to
https://github.com/driusan/PoormanIssueTracker
https://github.com/driusan/IssueTrackerTools
https://github.com/aaiyer/bugseverywhere

Each issue is kept in separate directory. Directory's name is the
issue's brief name. Dashes should be interpreted as spaces and n > 1
dashes should be interpreted as n-1 dashes when converting the directory
name to a human readable issue title, as PoormanIssueTracker suggests.

The "about" file contains the description of the issue. The "result"
(initially empty) contains the resolved issue information. The "meta"
file contains metainformation in recfile format, having at least
"created" fields. https://www.gnu.org/software/recutils/

Root directory should contain *.rec files with the schema of the
records. For example:

    person.rec:
        %rec: person
        %key: id
        %unique: name
        %mandatory: name email
        %type: id line
        %type: name line
        %type: email email

        id: stargrave
        name: Сергей Матвеев
        email: stargrave@stargrave.org

    task.rec:
        %rec: task
        %key: id
        %mandatory: name created
        %unique: name created about result
        %allowed: about result ass proj status
        %sort: created
        %type: id line
        %type: name line
        %type: created date
        %type: ass rec person
        %type: proj enum
        + c (C99)
        + go (Go)
        + py (Python3)
        + tcl (Tcl)
        %type: status enum
        + done (task is finished)
        + reject
        + wip (work in progress)

Schema of the issues/tasks must be trailing *.rec file after the sort.

Want to search among the issues? Just use git grep, or ordinary grep!
Want to search through attached PDFs or other kind of documents? You are
free to index issues directory with something like recoll. Want to see
the whole history of changes related to specific issues? Just run
git log issue-name!

You can edit meta files either manually (it is trivial text-based
human-friendly format) or with recset utility. Add "deps: foo-bar" field
and press "gf" in your Vi editor to go to "foo-bar" directory of the
dependant issue.

"metas" script exports the whole issues database without about/result
fields. "show" includes them. "full" also prepends *.rec files to the
output. They are expected to be filtered with recsel/recdel utilities.
"cd" lists all issues piped to "fzf" utility, that previews each one
with "show" script.

The "comment" issue's file is intended to keep the last comment related to
the issue. By committing it you automatically accompany it with your
(commit's author) name and the time it was added.

    $ cat >issues-name/comment <<EOF
    Here are my thoughts:
    * bla bla bla
    EOF
    $ git commit issues-name/comment

And you can view all comments/authors history later just with:

    $ git log -p issues-name/comment

Personally I "hash -d" schwabrak's directory to be able to quickly call
commands from it:

    $ hash -d s=~/work/schwabrak
    $ cd my/issues
    $ ~s/add issue name to create

To ease the creation of the new issue's directory structure, you can use
"add" command as seen above. And yes, it is intended that "issue" and
"name", "to", "create" can be passed as separate arguments, but
issue-name-to-create will be created as expected.