first experiences with DITrack

[Vlad Skvortsov]

A.T.Hofkamp wrote:
> Hello,
>
> I was looking for a small issue tracker for some personal projects, and found 
> DITrack. It seems to match nicely with my use of SVN (and not so nicely with 
> my use of Combinator, but more about that later).
>
> Below are my first experiences.
>
>
>
> - 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.

> - You seem to use versions a lot, both as where the bug is found and when the 
> issue is fixed. I have a lot less need for them (especially the latter), 
> wouldn't it be possible to leave the fields open?
>   

I've opened i#167 to address that. Scheduled for 0.7.

> - Why do you ask me which version when only one option exists?
>   

Hmm, I guess the answer is "for consistency". Basically, I don't want to 
think whether particular menu has one or multiple choices. If menus with 
only one choice get skipped it's harder (for me) to mentally track 
"where I am in the UI workflow".

I think we can make it a configurable client option though.

> - 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. :-)

I don't have a strong preference here: what do others think? How about 
having 't) - add/edit comment text'?

> - Webpage document format of files is not correct w.r.t. reality. The examples 
> don't work. Maybe you could add a unit test with the web-page values, with a 
> note that when changing the tests, the page should also be changed?
>   

Yeah. It is a good idea, but unfortunately we don't have enough 
resources to write the supplementary glue code for that. :-(

As for the web site itself, it badly needs to be updated, I agree. We 
have started working on that and Oleg has a proposal on the new version 
of the site.

> - 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).
> I use Combinator (http://divmod.org/trac/wiki/DivmodCombinator) for my 
> projects (part of UQDS 
> (http://divmod.org/trac/wiki/UltimateQualityDevelopmentSystem)).
>
> The structure of this is
>
> ~/projects/Proj1/trunk/.....
> ~/projects/Proj1/branch/branch1/.....
> ~/projects/Proj1/branch/branch2/.....
>
> A common ~/projects directory, then for each project Proj1, Proj2, etc a 
> directory trunk (the trunk WC), and zero or more branch WCs in 
> branches/branchX/...
> The logical place for DITrack data is at ~/projects/Proj1/issues, 
> ~/projects/Proj2/issues, etc.
> With that setup, I now have to change the value of the environment variable 
> each time instead of just changing directory.
>   

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

> Last but not least:
>
>
> Although it is not optimal yet, I like the idea and functionality.
>   

Cool :-)

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

-- 
Vlad Skvortsov, vss at 73rus.com, http://vss.73rus.com