ohac-ditz 0.5.1

data/Manifest.txt

@@ -0,0 +1,48 @@
+Changelog
+INSTALL
+LICENSE
+Manifest.txt
+PLUGINS.txt
+README.txt
+Rakefile
+ReleaseNotes
+bin/ditz
+contrib/completion/_ditz.zsh
+contrib/completion/ditz.bash
+lib/ditz.rb
+lib/ditz/file-storage.rb
+lib/ditz/hook.rb
+lib/ditz/html.rb
+lib/ditz/lowline.rb
+lib/ditz/model-objects.rb
+lib/ditz/model.rb
+lib/ditz/operator.rb
+lib/ditz/plugins/git-sync.rb
+lib/ditz/plugins/git.rb
+lib/ditz/plugins/issue-claiming.rb
+lib/ditz/plugins/issue-labeling.rb
+lib/ditz/plugins/issue-timetracker.rb
+lib/ditz/util.rb
+lib/ditz/view.rb
+lib/ditz/views.rb
+share/ditz/index.rhtml
+share/ditz/issue.rhtml
+share/ditz/issue_table.rhtml
+share/ditz/release.rhtml
+share/ditz/unassigned.rhtml
+share/ditz/component.rhtml
+share/ditz/style.css
+share/ditz/blue-check.png
+share/ditz/green-bar.png
+share/ditz/green-check.png
+share/ditz/red-check.png
+share/ditz/yellow-bar.png
+man/man1/ditz.1
+setup.rb
+bin/coditz.rb
+bin/coditz_for_0.5.rb
+contrib/bookmarklet.js
+lib/ditz/plugins/icalendar.rb
+lib/ditz/plugins/mercurial.rb
+lib/ditz/plugins/sha-names.rb
+sheila/sheila.rb

data/PLUGINS.txt

@@ -0,0 +1,197 @@
+Ditz plugin documentation
+-------------------------
+
+Ditz features a code plugin system for adding and extending commands, fields,
+and output. Ditz's plugin system is used to add optional functionality to Ditz.
+
+If you're interested in writing a plugin, look at the simple plugins in
+lib/ditz/plugin/, and see
+  http://all-thing.net/2008/07/ditz-04-and-magic-of-ruby-dsls.html
+If you're interested using plugins, read on.
+
+Ditz loads specific plugins by looking for a .ditz-plugins file in the project
+root. The format of this file is a YAML array of strings, where each string is
+a plugin name. You can write this by hand like this:
+
+  - my-plugin
+  - another-plugin
+
+I.e. one plugin name per line, prefixed by "- " as the first two characters of each line.
+
+For each listed plugin name, Ditz looks for a file named
+"lib/ditz/plugin/<name>.rb" within Ruby's default search path. Assuming Ditz is
+installed in a standard manner, you should have available to you the following
+shipped plugins:
+
+1. git
+2. git-sync
+3. icalendar
+4. issue-claiming
+5. issue-labeling
+6. issue-timetracker
+7. mercurial
+8. sha-names
+
+git
+---
+
+This plugin allows issues to be associated with git commits and git
+branches.  Git commits can be easily tagged with a ditz issue with the 'ditz
+commit' command, and both 'ditz show' and the ditz HTML output will then
+contain a list of associated commits for each issue.
+
+Issues can also be assigned a single git feature branch. In this case, all
+commits on that branch will listed as commits for that issue. This
+particular feature is fairly rudimentary, however---it assumes the reference
+point is the 'master' branch, and once the feature branch is merged back
+into master, the list of commits disappears.
+
+Two configuration variables are added, which, when specified, are used to
+construct HTML links for the git commit id and branch names in the generated
+HTML output.
+
+Commands added:
+  ditz set-branch: set the git branch of an issue
+  ditz commit: run git-commit, and insert the issue id into the commit
+    message.
+
+Usage: 
+  1. add a line "- git" to the .ditz-plugins file in the project root
+  2. run ditz reconfigure, and enter the URL prefixes, if any, from
+     which to create commit and branch links.
+  3. use 'ditz commit' with abandon.
+
+git-sync
+--------
+
+This plugin is useful for when you want synchronized, non-distributed issue
+coordination with other developers, and you're using git. It allows you to
+synchronize issue updates with other developers by using the 'ditz sync'
+command, which does all the git work of sending and receiving issue change
+for you. However, you have to set things up in a very specific way for this
+to work:
+
+1. Your ditz state must be on a separate branch. I recommend calling it
+   'bugs'. Create this branch, do a ditz init, and push it to the remote
+   repo. (This means you won't be able to mingle issue change and code
+   change in the same commits. If you care.)
+2. Make a checkout of the bugs branch in a separate directory, but NOT in
+   your code checkout. If you're developing in a directory called "project",
+   I recommend making a ../project-bugs/ directory, cloning the repo there
+   as well, and keeping that directory checked out to the 'bugs' branch.
+   (There are various complicated things you can do to make that directory
+   share git objects with your code directory, but I wouldn't bother unless
+   you really care about disk space. Just make it an independent clone.)
+3. Set that directory as your issue-dir in your .ditz-config file in your
+   code checkout directory. (This file should be in .gitignore, btw.)
+4. Run 'ditz reconfigure' and fill in the local branch name, remote
+   branch name, and remote repo for the issue tracking branch.
+
+Once that's set up, 'ditz sync' will change to the bugs checkout dir, bundle
+up any changes you've made to issue status, push them to the remote repo,
+and pull any new changes in too. All ditz commands will read from your bugs
+directory, so you should be able to use ditz without caring about where
+things are anymore.
+
+This complicated setup is necessary to avoid accidentally mingling code
+change and issue change. With this setup, issue change is synchronized,
+but how you synchronize code is still up to you.
+
+Usage:
+  0. read all the above text very carefully
+  1. add a line "- git-sync" to the .ditz-plugins file in the project
+     root
+  2. run 'ditz reconfigure' and answer its questions
+  3. run 'ditz sync' with abandon
+
+icalendar
+---------
+
+This plugin adds ability to export full todo list in iCalendar (RFC 2445) format. 
+It is useful for integration with different pim software like KOrganizer.
+
+Issues are converted to VTODO entries with completion status set to 50 if
+its state is :in_progress, 100 if it's closed and 0 otherwise.
+Progress for release is 100 if it's released otherwise it's 99 * closed/all 
+issues. So maximum for active release is 99 and it's not shown as done until 
+released.
+
+Commands added:
+  ditz todo-ics: generate full todo list in iCalendar format
+
+Usage: 
+  1. add a line "- icalendar" to the .ditz-plugins file in the project root
+
+issue-claiming
+--------------
+
+This plugin allows people to claim issues. This is useful for avoiding
+duplication of work---you can check to see if someone's claimed an
+issue before starting to work on it, and you can let people know what
+you're working on.
+
+Commands added:
+  ditz claim: claim an issue for yourself or a dev specified in project.yaml
+  ditz unclaim: unclaim a claimed issue
+  ditz mine: show all issues claimed by you
+  ditz claimed: show all claimed issues, by developer
+  ditz unclaimed: show all unclaimed issues
+
+Usage:
+  1. add a line "- issue-claiming" to the .ditz-plugins file in the project
+     root
+  2. (optional:) add a 'devs' key to project.yaml, e.g:
+devs: 
+  :roy: Roy Baty <roy@marsproject.com>
+  :pris: Pris Stratton <pris@marsproject.com>
+
+issue-labeling
+--------------
+
+This plugin allows label issues. This can replace the issue component
+and/or issue types (bug,feature,task), by providing a more flexible
+to organize your issues.
+
+Commands added:
+  ditz new_label [label]: create a new label for the project
+  ditz label <issue> <labels>: label an issue with some labels
+  ditz unlabel <issue> [labels]: remove some label(s) of an issue
+  ditz labeled <labels> [release]: show all issues with these labels
+
+Usage:
+  1. add a line "- issue-labeling" to the .ditz-plugins file in the project
+     root
+  2. use the above commands to abandon
+
+issue-timetracker
+-----------------
+
+module Ditz
+
+mercurial
+---------
+
+require 'time'
+
+sha-names
+---------
+
+This world's-smallest-ditz-plugin uses the initial 5 characters of
+the SHA id instead of an identifier like "ditz-999".  Installing
+this plugin will cause all references of the form 'ditz-123' and
+'engine-57' to change to '1a2bc', 'f33d0' and similarly memorable
+IDs.  If you are comfortable working with them (your clients may
+not be...)  these make all issue IDs unique across the project, so
+long as you do not get a collision between two 5-hex-char IDs.
+
+Without this plugin, the standard ID for an issue will be of the
+form 'design-123'. Whilst this is easier to remember, it is also
+liable to change - for example, if two ditz trees are merged
+together, or if an issue is re-assigned from one component to
+another. This plugin provides a canonical, immutable ID from the
+time of issue creation.
+
+Usage: 
+  1. add a line "- sha-names" to the .ditz-plugins file in the
+  project root
+

data/README.txt

@@ -0,0 +1,146 @@
+== ditz
+
+by William Morgan <wmorgan-ditz at the masanjin dot nets>
+
+http://ditz.rubyforge.org
+
+== DESCRIPTION
+
+Ditz is a simple, light-weight distributed issue tracker designed to work with
+distributed version control systems like git, darcs, Mercurial, and Bazaar. It
+can also be used with centralized systems like SVN.
+
+Ditz maintains an issue database directory on disk, with files written in a
+line-based and human-editable format. This directory can be kept under version
+control, alongside project code.
+
+Ditz provides a simple, console-based interface for creating and updating the
+issue database files, and some basic static HTML generation capabilities for
+producing world-readable status pages (for a demo, see the ditz ditz page).
+
+Ditz includes a robust plugin system for adding commands, model fields, and
+modifying output. See PLUGINS.txt for documentation on the pre-shipped plugins.
+
+Ditz currently offers no central public method of bug submission. 
+
+== USING DITZ
+
+There are several different ways to use Ditz:
+
+1. Treat issue change the same as code change: include it as part of commits,
+   and merge it with changes from other developers, resolving conflicts in the
+   usual manner.
+2. Keep the issue database in the repository but in a separate branch. Issue
+   changes can be managed by your VCS, but is not tied directly to code
+   commits.
+3. Keep the issue database separate and not under VCS at all.
+
+All of these options are supported; the choice of which to use depends on your
+workflow.
+
+Option #1 is probably most appropriate for the unsynchronized, distributed
+development, since it allows individual developers to modify issue state with a
+minimum of hassle. Option #2 is most suitable for synchronized development, as
+issue state change can be transmitted independently of code change (see also
+the git-sync plugin) and can act as a sychronization mechanism. Option #3 is
+only useful with some other distribution mechanism, like a central web
+interface.
+
+== COMMANDLINE SYNOPSIS
+
+# set up project. creates the bugs.yaml file.
+1. ditz init
+2. ditz add-release
+
+# add an issue
+3. ditz add
+
+# where am i?
+4. ditz status
+5. ditz todo (or simply "ditz")
+
+# do work
+6. write code
+7. ditz close <issue-id>
+8. commit
+9. goto 3
+
+# finished!
+10. ditz release <release-name>
+
+== THE DITZ DATA MODEL
+
+By default, Ditz includes the bare minimum set of features necessary for
+open-source development. Features like time spent, priority, assignment of
+tasks to developers, due dates, etc. are purposely relegated to the plugin
+system.
+
+A Ditz project consists of issues, releases and components.
+
+Issues:
+  Issues are the fundamental currency of issue tracking. A Ditz issue is either
+  a feature or a bug, but this distinction currently doesn't affect anything
+  other than how they're displayed.
+
+  Each issue belongs to exactly one component, and is part of zero or one
+  releases.
+
+  Each issues has an exportable id, in the form of 40 random hex characters.
+  This id is "guaranteed" to be unique across all possible issues and
+  developers, present and future. Issue ids are typically not exposed to the
+  user.
+
+  Issues also have a non-global, non-exportable name, which is short and
+  human-readable. All Ditz commands use issue names in addition to issue ids.
+  Issue names (but not issue ids) may change in certain circumstances, e.g.
+  after a "ditz drop" command.
+
+  Issue names can be specified in comments, titles and descriptions, and Ditz
+  will automatically rewrite them as necessary when they change.
+
+Components:
+  There is always one "general" component, named after the project itself. In
+  the simplest case, this is the only component, and the user is never bothered
+  with the question of which component to assign an issue to.
+
+  Components simply provide a way of organizing issues, and have no real
+  functionality. Issues names are derived from the component they're assigned
+  to.
+
+Releases:
+  A release is the primary grouping mechanism for issues. Status commands like
+  "ditz status" and "ditz todo" always group issues by release. When a release
+  is 100% complete, it can be marked as released, and its issues will cease
+  appearing in Ditz status and todo messages.
+
+== LEARNING MORE
+
+* ditz help
+* find $DITZ_INSTALL_DIR -type f | xargs cat
+
+== REQUIREMENTS
+
+* trollop >= 1.8.2, if running via RubyGems.
+
+== INSTALLATION
+
+Download tarballs from http://rubyforge.org/projects/ditz/, or command your
+computer to "gem install ditz".
+
+== LICENSE
+
+Copyright (c) 2008 William Morgan.
+
+This program is free software: you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation, either version 3 of the License, or
+(at your option) any later version.
+
+Additionally, this program may be linked to, distributed with, used with,
+and/or loaded with the Ruby "Trollop" library.
+
+This program is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+GNU General Public License for more details.
+

data/Rakefile

@@ -0,0 +1,66 @@
+require 'rubygems'
+require 'hoe'
+
+$:.unshift "lib"
+require 'ditz'
+
+class Hoe
+  def extra_dev_deps; @extra_dev_deps.reject { |x| x[0] == "hoe" } end
+end
+
+Hoe.new('ditz', Ditz::VERSION) do |p|
+  p.rubyforge_name = 'ditz'
+  p.author = "William Morgan"
+  p.summary = "A simple issue tracker designed to integrate well with distributed version control systems like git and darcs. State is saved to a YAML file kept under version control, allowing issues to be closed/added/modified as part of a commit."
+
+  p.description = p.paragraphs_of('README.txt', 4..11).join("\n\n").gsub(/== SYNOPSIS/, "Synopsis:")
+  p.url = "http://ditz.rubyforge.org"
+  p.changes = p.paragraphs_of('Changelog', 0..0).join("\n\n")
+  p.email = "wmorgan-ditz@masanjin.net"
+  p.extra_deps = [['trollop', '>= 1.9'], ['yaml_waml', '>= 0.3']]
+end
+
+WWW_FILES = FileList["www/*"] + %w(README.txt PLUGINS.txt)
+
+task :upload_webpage => WWW_FILES do |t|
+  sh "rsync -essh -cavz #{t.prerequisites * ' '} wmorgan@rubyforge.org:/var/www/gforge-projects/ditz/"
+end
+
+task :upload_report do |t|
+  sh "ruby -Ilib bin/ditz html ditz"
+  sh "rsync -essh -cavz ditz wmorgan@rubyforge.org:/var/www/gforge-projects/ditz/"
+end
+
+task :plugins  do |t|
+  sh "ruby -w ./make-plugins.txt.rb > PLUGINS.txt"
+end
+
+task :really_check_manifest do |t|
+  f1 = Tempfile.new "manifest"; f1.close
+  f2 = Tempfile.new "manifest"; f2.close
+  sh "git ls-files | egrep -v \"^bugs/\" | sort > #{f1.path}"
+  sh "sort Manifest.txt > #{f2.path}"
+
+  f3 = Tempfile.new "manifest"; f3.close
+  sh "diff -u #{f1.path} #{f2.path} > #{f3.path}; /bin/true"
+
+  left, right = [], []
+  IO.foreach(f3.path) do |l|
+    case l
+    when /^\-\-\-/
+    when /^\+\+\+/
+    when /^\-(.*)\n$/; left << $1
+    when /^\+(.*)\n$/; right << $2
+    end
+  end
+
+  puts
+  puts "Tracked by git but not in Manifest.txt:"
+  puts left.empty? ? "  <nothing>" : left.map { |l| "  " + l }
+
+  puts
+  puts "In Manifest.txt, but not tracked by git:"
+  puts right.empty? ? "  <nothing>" : right.map { |l| "  " + l }
+end
+
+# vim: syntax=ruby

data/ReleaseNotes

@@ -0,0 +1,56 @@
+0.5
+---
+
+Two new plugins: git-sync, for synchronized git usage, and issue-claiming,
+which allows you to claim issues for yourself. See PLUGINS.txt for details.
+
+0.4
+---
+- Command-line completion scripts are now included for bash and zsh. To
+  activate, source the relevant file in $GEMDIR/ditz-0.4/contrib/completion/.
+
+- Hooks can now be set on a per-project basis. Make a .ditz/hooks directory in
+  your project root and place them there. These will be loaded after any
+  hooks in ~/.ditz/hooks, so they can override or simply supplement.
+
+- The plugin system is done. There's currently one plugin, for git integration.
+  To enable it, add the line "- git" in a .ditz-plugins file in your project
+  root. The git plugin currently has the following features:
+
+  - Issues can have a git branch assigned to them with "ditz set-branch".
+  - Git commit messages can have a Ditz-issue: header auto-filled if you
+    commit with "ditz commit <issue>" (i.e. instead of git commit).
+  - In both HTML and screen output, commits from the assigned branch, and
+    commits with the corresponding Ditz-issue: header in the log message,
+    will be listed for each issue.
+
+  Note that the plugin system is independent of the hook system. In order
+  to auto-add ditz files to the git index upon modification, you must set
+  up hooks. Example hooks for git are at:
+    http://hackety.org/2008/06/26/gitHooksForDitz.html
+
+  Also note that as soon as a feature branch is merged back into master, ditz
+  loses the ability to distinguish its commits. So the Ditz-issue: approach
+  is probably better if you want a long-term record.
+
+0.3
+---
+Ditz now works from project subdirectories, and you can have a .ditz-config in
+the project root for project-specific configuration. (This is not merged with
+the global config, so this file overrides everything in ~/.ditz-config.)
+
+You can specify an :issue_dir key in this file, which can be a relative path to
+the directory containing project.yaml. So if you want to rename that directory,
+or keep it somewhere else, now you can.
+
+There's also a new hook system for plugging in your own code. Run ditz -l to
+see a list of available hooks.
+
+0.2
+---
+
+In ditz 0.2, we store issues per file. This avoids many unnecessary conflicts
+that occur in the single-file case.
+
+To upgrade your bugs.yaml to a bugs/ directory, you must run
+ditz-convert-from-monolith.