1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
|
<html><head><meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1"><title>DITrack Manual</title><meta name="generator" content="DocBook XSL Stylesheets V1.70.1"><link rel="start" href="#ditrack" title="DITrack Manual"><link rel="next" href="#id904838" title="Chapter1.Overview"></head><body bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><div class="book" lang="en"><div class="titlepage"><div><div><h1 class="title"><a name="ditrack"></a>DITrack Manual</h1></div><div><h2 class="subtitle">Version 0.4</h2></div><div><h3 class="corpauthor">The DITrack Project</h3></div><div><p class="copyright">Copyright 2006 The DITrack Project</p></div><div><div class="legalnotice"><a name="id904808"></a><p>
This work is licensed under the BSD license terms. The full
text of the license is available
<a href="http://www.ditrack.org/LICENSE" target="_top">here</a>.
</p></div></div><div><p class="pubdate">Oct, 2 2006</p></div></div><hr></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="chapter"><a href="#id904838">1. Overview</a></span></dt><dd><dl><dt><span class="sect1"><a href="#id904848">Audience</a></span></dt><dt><span class="sect1"><a href="#id904857">System Design</a></span></dt><dt><span class="sect1"><a href="#id904927">The Ontology</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id904933">Issues</a></span></dt><dt><span class="sect2"><a href="#id905058">Users</a></span></dt><dt><span class="sect2"><a href="#id905072">Categories</a></span></dt><dt><span class="sect2"><a href="#id905089">Versions</a></span></dt></dl></dd></dl></dd><dt><span class="chapter"><a href="#id905374">2. Installation</a></span></dt><dt><span class="chapter"><a href="#id905474">3. Usage</a></span></dt><dd><dl><dt><span class="sect1"><a href="#id905510">Getting Help</a></span></dt><dt><span class="sect1"><a href="#id905537">Specifying Database To Use</a></span></dt><dt><span class="sect1"><a href="#id905576">Other Environment Settings</a></span></dt><dt><span class="sect1"><a href="#id905594">Bootstrapping</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id905600">Database Initialization</a></span></dt><dt><span class="sect2"><a href="#id905661">Database Configuration</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id905872">Regular Work Cycle</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id905862">Adding A New Issue</a></span></dt><dt><span class="sect2"><a href="#id905882">Acting On An Existing Issue</a></span></dt><dt><span class="sect2"><a href="#id905942">Querying The Database</a></span></dt></dl></dd></dl></dd></dl></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id904838"></a>Chapter1.Overview</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id904848">Audience</a></span></dt><dt><span class="sect1"><a href="#id904857">System Design</a></span></dt><dt><span class="sect1"><a href="#id904927">The Ontology</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id904933">Issues</a></span></dt><dt><span class="sect2"><a href="#id905058">Users</a></span></dt><dt><span class="sect2"><a href="#id905072">Categories</a></span></dt><dt><span class="sect2"><a href="#id905089">Versions</a></span></dt></dl></dd></dl></div><p>
DITrack is an issue tracking system. Its primary purpose is to
store and organize text records that reflect real-world issues
an organization has to deal with. The system is primarily
targeted to small software projects with flat organizational
structure (where no complex access control policies have to
be enforced).
</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id904848"></a>Audience</h2></div></div></div><p>
This document is a general system architecture overview and a
user manual at the same time. It is assumed that the reader is
familiar with Subversion version control system and has a basic
knowledge of UNIX environment.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id904857"></a>System Design</h2></div></div></div><p>
DITrack uses a Subversion repository to store its data. The
repository is used merely as a distributed versioned file
system: DITrack makes no assumptions about its layout. The
diagram below displays the system structure.
</p><pre class="screen">
Server side Client side
+-------------------+ +-------------------+
| Subversion server |----------------| Subversion Client |
+-------------------+ +-------------------+
/ | \
/ | +--------------+
(DITrack Pre-Commit Hook) | | Working copy |
/ | +--------------+
+------------+ | /
| Repository | +----------------+
+------------+ | DITrack Client |
+----------------+
|
|
+----------------+
| End User |
| Or Software |
| Component |
+----------------+
</pre><p>
The diagram shows only single client instance; however there
may be a number of them. Each client has a working copy which
contains a snapshot of DITrack issues database. Since the latter
is just a subtree of a Subversion repository, single repository
may contain unlimited number of DITrack databases. Again, since
the issues database is just a Subversion working copy, usual
rules of dealing with that apply: it should be periodically
updated (i.e. synchronized with the repository by 'svn
update').
</p><p>
All data files DITrack makes use of within the working copy are
plain text (mostly conforming to RFC2822 message format). In a
case when the DITrack client is not available, a user may just
hand-edit the files with any ASCII text editor and commit the
changes.
</p><p>
However, since the issue database is a set of related entities,
the consistency should always be preserved (at least at the
synchronization points, i.e. when an 'svn update' or 'svn
commit' happens). To enforce data consistency, a pre-commit
hook script is installed on the server side. It basically
ensures that the transaction which is about to be committed
doesn't break the database consistency. Thus, even is a user
edits data files manually, the database won't get corrupted.
</p><p>
<span class="emphasis"><em>NB!</em></span>
As of version 0.4, there is <span class="emphasis"><em>no</em></span>
server-side hook. It will be implemented in a future release.
</p><p>
It is worth noting that instead of a human user the client
might be a software component that acts on behalf of the user.
This way, for example, a web interface or e-mail integration
facility for the issues database may be built.
</p><p>
Also note that DITrack on the client side is only a driver which
controls Subversion client. The former does not initiate or
handle any network activities. Its role is limited
to modifications of local working copy and running appropriate
Subversion commands to synchronize with the repository.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id904927"></a>The Ontology</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id904933"></a>Issues</h3></div></div></div><p>
The data model used by DITrack is designed to be as simple
and general as possible. The basic entity class is the
issue - a collection of (primarily) textual records
describing real-world issue and the progress being done
to resolve that. Each issue is assigned a unique
numeric identifier. The very first issue in a database
is assigned identifier 1 and each following one is
given the next integral number.
</p><p>
Each issue consists of a header and a description; it
can also have comments added and files attached.
</p><p>
An issue header contains a number of fields that are
used by DITrack and can also have arbitrary user-specified
fields (provided they conform to certain syntax rules).
DITrack makes use of the following fields:
</p><div class="variablelist"><dl><dt><span class="term">Category</span></dt><dd>
A category the issue falls into.
</dd><dt><span class="term">Due-in</span></dt><dd>
Current estimate of the issue
resolution deadline.
</dd><dt><span class="term">Opened-by</span></dt><dd>
An identifier of the user who
originally opened the issue.
</dd><dt><span class="term">Opened-on</span></dt><dd>
A timestamp when the issue was
initially opened.
</dd><dt><span class="term">Owned-by</span></dt><dd>
An identifier of a user who is
currently responsible for resolving
the issue.
</dd><dt><span class="term">Reported-for</span></dt><dd>
A version of a product the issue was
reported against.
</dd><dt><span class="term">Status</span></dt><dd>
Current status of the issue: "open" or
"closed".
</dd><dt><span class="term">Title</span></dt><dd>
A short description of the issue.
</dd></dl></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905058"></a>Users</h3></div></div></div><p>
The system has a notion of users. Each user has an
identifier which is basically the user's login name.
There are no roles or access rights attributed to any
user in the system.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905072"></a>Categories</h3></div></div></div><p>
Issues handled by the system fall into different
categories. Hence the notion of the latter. Each
category has an identifier which is a sequence of
non-blank characters. The name space for the categories
is flat (i.e. the names are not structured in any sort
of hierarchy that DITrack is aware of); however it is
possible to imitate tree structure by crafting
category names according to certain rules. For example,
the following category names are treated as
flat by DITrack but are perceived as hierarchially
organized: "unknown", "frontend",
"frontent/user-editor", "backend", "backend/server",
"backend/tools", "backend/tools/cleaner", etc.
"-" cannot be used as a category name.
</p><p>
Each category is associated with a version set.
Different categories may share common version sets.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905089"></a>Versions</h3></div></div></div><p>
Versions represent different time points in a lifetime
of a product. Obviously they are not strictly tied to
real version numbers; they may represent arbitrary
milestones in a development cycle. Version names are
sequences of non-blank characters; "/" cannot be used
as a version name.
</p><p>
Versions are arranged into sets. Since a single project
may contain several products released on different
schedules, different version sets may be used to track
each product development. Version names within a set
are divided into three groups ("tenses"): "past"
versions, "current" versions and "future" versions.
</p><p>
The notion of "tenses" is introduced to aid a user in
dealing with potentially large version sets. A product
may have a huge number of versions released per its
lifetime; however, when filing a bug report or planning
the features for a couple of nearest releases of a
product, a user needs only a handful of versions to
consider. Thus, "future" versions are used for
planning: the target milestone for the issue (the
"Due-in" header field) may contain only a future
version name. The "current" versions are used when
reporting an issue: they indicate all versions of
product that are currently in use. And finally the
"past" versions represent versions of product that are
no longer supported: their names cannot appear in an
open issue.
</p></div></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id905374"></a>Chapter2.Installation</h2></div></div></div><p>
As of now, DITrack doesn't have an installation routine.
DITrack itself is a couple of Python and Shell scripts and
modules. Thus, it can be used without regular system-wide
installation.
</p><p>
Alternatively, DITrack may be installed system-wide
manually as follows:
</p><div class="orderedlist"><ol type="1"><li><p>
Copy the 'dt' and 'dt-createdb' files to
the location where your locally
installed binaries reside. Most
probably, it is '/usr/local/bin',
'/opt/bin' or alike.
</p></li><li><p>
Copy the 'DITrack' directory to the
location where your locally installed
Python modules reside.
Most probably, it is '/usr/local/lib/python'
or alike.
</p></li></ol></div></div><div class="chapter" lang="en"><div class="titlepage"><div><div><h2 class="title"><a name="id905474"></a>Chapter3.Usage</h2></div></div></div><div class="toc"><p><b>Table of Contents</b></p><dl><dt><span class="sect1"><a href="#id905510">Getting Help</a></span></dt><dt><span class="sect1"><a href="#id905537">Specifying Database To Use</a></span></dt><dt><span class="sect1"><a href="#id905576">Other Environment Settings</a></span></dt><dt><span class="sect1"><a href="#id905594">Bootstrapping</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id905600">Database Initialization</a></span></dt><dt><span class="sect2"><a href="#id905661">Database Configuration</a></span></dt></dl></dd><dt><span class="sect1"><a href="#id905872">Regular Work Cycle</a></span></dt><dd><dl><dt><span class="sect2"><a href="#id905862">Adding A New Issue</a></span></dt><dt><span class="sect2"><a href="#id905882">Acting On An Existing Issue</a></span></dt><dt><span class="sect2"><a href="#id905942">Querying The Database</a></span></dt></dl></dd></dl></div><p>
The DITrack command line client and the script to create new issue
databases are named 'dt' and 'dt-createdb' respectively. The
former is a Python script that uses library modules distributed
with the system in 'DITrack' subdirectory.
So make sure that the modules are available in system paths for
Python modules (PYTHONPATH environment variable, see
<a href="http://docs.python.org/tut/node8.html#SECTION008110000000000000000" target="_top">
Python manual
</a>
for details) or in current directory. This means that
if you have not installed DITrack system-wide, you'll need to
change current directory to the one where DITrack resides each
time you run 'dt'.
</p><p>
All following examples assume that DITrack is installed
system-wide. '$' represents shell prompt here.
</p><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id905510"></a>Getting Help</h2></div></div></div><p>
You can always get a brief help message with a list of
available commands by issuing:
</p><pre class="screen">$ dt help</pre><p>
To get help for specific command, append its name
after 'help', as in
</p><pre class="screen">$ dt help act</pre></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id905537"></a>Specifying Database To Use</h2></div></div></div><p>
The 'dt' script assumes that the current directory is
the root of the issues database you want to work with.
There are two ways to change this assumption.
</p><p>
DITrack checks the DITRACK_ROOT environment variable, and
if it's set, its value is used to reference an issue
database. In a Bourne shell, it may be set with the
the command like the following:
</p><pre class="screen">$ export DITRACK_ROOT="/home/joe/myproj/issues"</pre><p>
Alternatively, the '-d' option may be used to specify
the location of a database. It has the highest
precedence so may be used to override DITRACK_ROOT
environment variable:
</p><pre class="screen">$ dt ls -d ~/some/other/issue/database</pre></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id905576"></a>Other Environment Settings</h2></div></div></div><p>
Since working with issues includes a fair bit of text
editing, DITrack needs to know which application to use
for that. Environment variable EDITOR should be set
upon invocation of any 'dt' command that might involve
editing.
</p></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id905594"></a>Bootstrapping</h2></div></div></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905600"></a>Database Initialization</h3></div></div></div><p>
DITrack needs an issue database to work on. It has
to be checked out and reside in a working copy
and be available for both reading and writing.
The database has certain structure, so it needs
to be created with special utility;
'dt-createdb' is the one to use for that
purpose.
</p><p>
An issue database is usually created on
per-project basis. Depending on your
preferences the Subversion repository you own
probably hosts one or multiple projects. This
detail is irrelevant here, since whatever
repository structure is, we'll consider only a
single project of that to use in the following
examples.
</p><p>
Suppose, the project structure in the
repository is as follows:
</p><pre class="screen">
projects/
myproj/
trunk/
branches/
1.0/
2.0/
tags/
1.0/
1.1/
</pre><p>
The natural placement for an issue database
with such a layout would be under 'myproj'
directory.
</p><p>
The following command will nonrecursively check
out specified repository path into
'myproj-root' directory and initialize issue
database named 'issues' in there.
</p><pre class="screen">$ dt-creatdb svn://server/projects/myproj issues myproj-root</pre><p>
The command will initialize database structure
without committing any changes to Subversion
repository. This action item is left for you
do. You might want to tweak the database
configuration as described below before
committing that to your repository.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905661"></a>Database Configuration</h3></div></div></div><p>
The first things you might wish to configure
for newly created issue database are: user
list, version sets and categories.
</p><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id905651"></a>User List</h4></div></div></div><p>
Users' identifiers are stored in the
'etc/users' file under a database root.
The syntax is simple: it's just a list
of user identifiers, one per line.
Example:
</p><pre class="screen">
joe
sally
rob
</pre><p>
You may edit the list with any text
editor and commit your changes
manually.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id905697"></a>Version Sets</h4></div></div></div><p>
Version sets are stored in the
'etc/versions' file under a database
root.
This configuration file defines one
version set per line. Each line is
arranged as follows:
</p><pre class="screen">
set-name: [pv [pv [ ...]]] / [cv [cv [ ...]]] / [fv [fv [ ...]]]
</pre><p>
where
</p><div class="variablelist"><dl><dt><span class="term">set-name</span></dt><dd>
is a name of the
version set;
</dd><dt><span class="term">pv</span></dt><dd>
is a name of a past
version;
</dd><dt><span class="term">cv</span></dt><dd>
is a name of a current
version;
</dd><dt><span class="term">fv</span></dt><dd>
is a name of a future
version.
</dd></dl></div><p>
Example:
</p><pre class="screen">
infrastructure-milestones: initial 200605 200606 / - / 200607 200608 sometimes
editor-versions: 1.0 2.0 2.1 / 2.2 3.0 3.1 / 2.3 3.2 4.0 5.0
backend-versions: 1.0.0 1.0.1 1.1 / 1.1.1 1.1.2 / 1.1.3 1.2.0 2.0
</pre></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id905789"></a>Categories</h4></div></div></div><p>
Category definitions are stored in the
'etc/categories' file under a database
root. The configuration file defines
one category per line. Each line is
arranged as follows:
</p><pre class="screen">
category-name: versions=version-set default-owner=user
</pre><p>where</p><div class="variablelist"><dl><dt><span class="term">category-name</span></dt><dd>
is a name of the
category being defined;
</dd><dt><span class="term">version-set</span></dt><dd>
is a name of the
version set associated
with this category;
</dd><dt><span class="term">user</span></dt><dd>
is an identifier of
a user who is the
default owner of issues
for this category.
</dd></dl></div><p>
Example:
</p><pre class="screen">
infrastructure: versions=infrastructure-milestones default-owner=joe
editor: versions=editor-versions default-owner=sally
backend: versions=backend-versions default-owner=rob
</pre></div></div></div><div class="sect1" lang="en"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="id905872"></a>Regular Work Cycle</h2></div></div></div><p>
There are three basic actions that can be performed
against an issue database: adding issues, acting on
existing issues and querying. Thus DITrack command line
client ('dt') features three basic commands for that:
'new', 'act' and 'ls'.
</p><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905862"></a>Adding A New Issue</h3></div></div></div><p>
To add a new issue, use the 'new' command. You
will be prompted to choose a category that the
new issue falls into, the version of a product
this issue is filed against, the issue title
and then shelled out into an editor to enter
the issue description. Once you are done with
that, you'll be finally asked for a due version
of this issue and upon that the newly added
issue will be committed into the database.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905882"></a>Acting On An Existing Issue</h3></div></div></div><p>
To take an action on an existing issue, use
the 'act' command. A menu of possible
actions will appear, which include
closing/reopening the issue, changing due
version, adding a comment, reassigning owner
and edition of the issue header.
</p><p>
It is also possible to act on several issues
at once. Just specify a list of issues as
arguments for the 'act' command:
</p><pre class="screen">$ dt act 10 14 28</pre><p>
Actions you take will apply to all listed
issues. Available menu options depend on the
particular issues properties. For example,
"change due version" menu option is only
available if all issues listed share the same
version set.
</p></div><div class="sect2" lang="en"><div class="titlepage"><div><div><h3 class="title"><a name="id905942"></a>Querying The Database</h3></div></div></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id905947"></a>Listing Existing Issues</h4></div></div></div><p>
The 'ls' command provides a way to
query an issues database. If run
without additional arguments, it dumps
a list of all existing issues.
</p><p>
Additional arguments may be supplied
that will be recognized as filter
expressions or predefined filter
names. If an argument doesn't look
like an expression (doesn't contain
'=', as of now), it's assumed to be
a predefined filter name.
</p><p>
Filter expression is a list of
comma-separated conditionals:
</p><pre class="screen">cond1,cond2,...condN</pre><p>
...where each condition
</p><pre class="screen">condX</pre><p> is a field name
and value, separated by an operator:
</p><pre class="screen">field{operator}value</pre><p>
Operators supported are '=' ("equals")
and '!=' ("doesn't equal").
</p><p>
A filter expression matches if all of
its conditionals match.
</p><p>
For example, the following command will
list all issues which status is "open"
and the owner is "joe":
</p><pre class="screen">$ dt ls Status=open,Owned-by=joe</pre><p>
Note that field names and values are
case-sensitive!
</p><p>
If several filter expressions are
specified, the output will include
issues that match any of the
expressions. The following command
will list issues owned by 'joe' or
'rob':
</p><pre class="screen">$ dt ls Owned-by=joe Owned-by=rob</pre><p>
Predefined filters associate filter
expressions with names to save
typing for frequently used queries.
The configuration file for predefined
filters is called 'filters' and resides
under 'etc' directory of an issue
database. The file lists predefined
filter names, one per line, followed by
a colon and a list of conditions as in
arguments for 'ls' command:
</p><pre class="screen">
1.0: Due-in=1.0,Status=open
1.1: Due-in=1.1,Status=open
closed: Status=closed
</pre><p>
...thus, with the configuration above
the invocation of:
</p><pre class="screen">$ dt ls 1.1</pre><p>
...is equivalent to:
</p><pre class="screen">$ dt ls Due-in=1.1,Status=open</pre><p>
In addition to this, the right side of
conditional expression may refer to
environment variable set at the time
of 'dt ls' invocation, like:
</p><pre class="screen">my: Owned-by=$USER</pre><p>
When invoked:
</p><pre class="screen">dt ls my</pre><p>
... 'my' will be treated as
'Owned-by=$USER' where '$USER' is
replaced with 'USER' environment
variable value.
</p></div><div class="sect3" lang="en"><div class="titlepage"><div><div><h4 class="title"><a name="id906100"></a>Viewing A Full Record Of An Issue</h4></div></div></div><p>
The 'cat' command dumps a full text of
an issue record to standard output.
</p></div></div></div></div></div></body></html>
|
