DITrack development

[Vlad Skvortsov]

Hey,

sorry for the delayed reply. I was quite busy with personal stuff 
recently, but now hope to get back on track.


Stefan Reichör wrote:
>> Do you need just some subset of DITrack command line client
>> functionality to be available in Emacs or the whole thing? I want to
>> get the idea what kind of integration you are looking for.
>>
>> Three possible approaches come to my mind at this point (the
>> applicability depends on your answer to the above question):
>>
>> 1. Invent command line switches to provide all required information.
>>     
>
> That is the way I would prefer. It has also the advantage for ditrack
> that ditrack is then fully scriptable.
>   

I guess the primary target for improving scriptability is the 'act' 
command, followed by 'new'. Let's start with 'act' and work our way for 
'new' later.

My [rough] proposal is to add the command line options to 'act' as follows:

* -m <string>
    Use the parameter as "comment text".

* -F <filename>
    Read "comment text" from the names file.

-m and -F are mutually exclusive. These options may be used only with -a:

-a <actionlist>
    Perform the list of actions from the list.

The "actionlist" is comma-separated list of actions to be applied to the 
issue:

* "close:<resolution>" - close the issue, with <resolution> being one of 
"dropped", "fixed" or "invalid".
* "change-due:<milestone>" - change the "due-in" milestone.
* "reassign:<user>" - reassign to another user.

Later we can add actions to modify header, etc.

Comments?

>> 2. Use the DITrack Python API from within a separate thin application
>> integrated into Emacs. This application may accept custom command line
>> parameters from Emacs and trigger the API for the real action.
>>     
>
> This application does already exist: It is called pymacs ;-)
> It allows to import python modules and use them via emacs. The
> parameters are converted from python to emacs lisp and the other way
> round.
>   

Great. So it looks it should be the cleanest way to interact with 
DITrack from within Emacs. The Python interface to DITrack was one of 
the goals of the nearest release (0.6).

>> 3. Create a "shell" around the command line client (similar to how our
>> test suite driver is constructed) to feed commands/data from Emacs to
>> dt's standard input.
>>     
>
> That could be done from within emacs since it can communicate with a
> running subprocess. That is probably the starting point for me.
>   

Yeah, it may be the easiest way to tie Emacs with *current* DITrack.

So overall, my suggestion would be to start with option #3, work towards 
option #2 for DITrack 0.6 and then aim for option #1 for DITrack 0.7. 
What are your thoughts?

[skipped]

>>> * Don't require to run svn co
>>> * Just create the issue-dir
>>> * Optionally add the issue-dir to a given revision control system
>>>
>>> I think this would be a first step for me to contribute to DITrack.
>>>   
>>>       
>> I suggest that the very first 'backend' would be a flat file system (I
>> referred to this as a 'null' backend before). So if you feel like
>> doing that, you should first factor out the svn-related stuff from the
>> script and add a support for the 'null' backend. This will require the
>> separation of backend-specific initialization from the rest of the
>> database setup. It would be a very good first step into the direction
>> we've decided to head.
>>     
>
> To be sure that I understand this correctly:
> The null backend is just an issues directory that is not controlled by
> any revision control system.
>   

Exactly.

> This means that it can only be used by a single user on a single
> platform. Or a user could use rsync or a similar system to synchronize
> different computers.
>   

Yep.

> My first step would be to improve dt-createdb to allow the
> initialization of an issues directory without the need for subversion.
>   

Yeah. I would first factor out backend-specific code into separate 
functions/classes, extend those to include 'null backend' and then add a 
command line switch to choose either way.

Hmm, I also think we should write the backend type to the database itself.

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