first experiences with DITrack

[A.T.Hofkamp]

Vlad Skvortsov wrote:
> A.T.Hofkamp wrote:

>> - I really liked to be able to specify a default set of columns for 
>> 'ls'. I am   missing the Categories, and have little use for 
>> submitter/owner (it is always me).
>>   
> 
> Yeah, this seems to be the most popular feature we are missing. :-) We 
> have i#20 opened for that, which I have just rescheduled to 0.6, due to 
> the demand.

Later I realized there is another feature I'd like to have, namely default 
filtering.

By default 'dt ls' lists all issues, while I'd like to have only the open 
issues. A simple addition could be to have a 'default:' entry in the filters 
to specify the default filtering.

This addition does imply that I would also need to be able to specify no 
filtering (ie I would need to be able to make a 'dt ls allissues' filter).

Maybe this is already possible by a filter line of the form

allissues:

but I haven't tried that yet, and I don't have ditrack nearby at the moment.


>> - with 'act', the 'edit comment' entry is confusing to me. 'Edit' to 
>> me means 'load file, change a bit, and save it again'. You edit 
>> concept is more 'add comment'. If you are fighting which letter to 
>> use, maybe use of T as in 'add text' would be a solution?
> 
> The thing is, you can type 'e' multiple times to edit previous versions 
> of your comment text. :-)

ok, more tests seem to be needed here :-)
Tnx.

>> - Not use DITRACK_ROOT?
 >
> In fact, you don't have to use it. I personally always point to an issue 
> database with '-d' option (shell aliases can help to deal with several 
> projects).

It is indeed an improvement compared with a hard-coded DITRACK_ROOT.
However, having a set of aliases added each time you start a new project also 
has a number of drawbacks.

>> The structure of this is
>>
>> ~/projects/Proj1/trunk/.....
>> ~/projects/Proj1/branch/branch1/.....
>> ~/projects/Proj1/branch/branch2/.....
 >>
>> The logical place for DITrack data is at ~/projects/Proj1/issues, 

> Can you take a look at i#147 
> (http://issues.ditrack.org/index.cgi?issue=147) and see if that would 
> address your problem?

It doesn't at this moment. SVN working copies start at the "....." 
sub-directories in my case, so there are no SVN properties in ~/projects/Proj1 
to query.

One solution would be to move the project in the repository to make it work as 
proposed. Whether that is a feasible solution for all cases is an open 
question to me.


As a possible alternative direction, what about having a set of path prefixes 
to relate ditrack roots to pwd?

For example, a ~/.ditrackrc file with lines like

[roots]
~/projects/Proj1/issues = ~/projects/Proj1

(I am using the ConfigParser syntax of section "[roots]" with key/value pairs 
seperated with a '=' character)


This configuration states that the ditrack "~/projects/Proj1/issues" working 
copy should be used whenever my pwd starts with "~/projects/Proj1".



Another solution would be the ability to specify a user-defined filename 
instead of a fixed svn property. However also in that case, you'd need a 
~/.ditrackrc resource file.


>> I read that you need documentation. What kind of documentation are you 
>> thinking about?
>>   
> 
> In fact, this question can be redirected to yourself. :-) What kind of 
> documentation you wished you had when started out with DITrack? I could 
> think of some kind of a "quick start" tutorial so that 1) new users 
> could quickly start using DITrack; 2) new visitors to the site could get 
> a feel of what it's like to work with DITrack.

You could redirect, but I am an exception to the rule in the sense that I 
normally read documentation before using software.

My preference is thus a detailed reference manual with *all* information in 
it. I can imagine that in general you'd like to have something less dense for 
starting users. :-)



Sincerely,
Albert