DITrack development

[Vlad Skvortsov]

Stefan Reichör wrote:


[skipped]

>>> My main interest would be to integrate ditrack in my familiar emacs
>>> environment.
>>>   
>>>       
>> All right, is there anything that needs to be changed on the DITrack
>> side for this?
>>     
>
> DITrack sometimes asks some interactive questions. It would be
> probably a bit easier, if all needed parameters can be passed to one
> command. I will post again, as soon I have some progress here.
>   

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.

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.

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.


[skipped]


>> There will be no movement in that direction until 0.7 though.
>>     
>
> Is there a roadmap or a release date for 0.7? ;-)
>   

Due to the way we work we have no deadlines for releases. Realistically 
speaking, it's this fall.

As for the roadmap, we have a rough idea of what will be implemented, 
but no formal roadmap.

http://issues.ditrack.org/?filter=0.7-mustfix


> I looked a bit at the DITrack source code.
> One thing that needs to be enhanced is the dt-createdb script.
> At the moment the support for svn is hardcoded. Additionally it will
> always checkout from a svn repository.
>
> What about the following changes/enhancements to allow the creation of
> an initial DITrack database for different backends:
>
> * Add a dt create-db command and drop the dt-createdb script
>   

There is a couple of reasons why I would prefer to have these things 
separate for now. My suggestion is to start modifying the script and see 
if there is much code to share with the command line client. If there 
is, we would work towards the generalization.


> * This would mean that the dt-createdb would be re-implemented in python
>   

It is, as of r1599.

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



[skipped]

> The most recent version of DITrack I have is 0.5
> Should I base my patches on that version? Or is there a way to access
> the development branch?
>   

You can check out the trunk from 
http://svn.xiolabs.com/ditrack/src/trunk and base your patches on that. 
Be warned though, that it might be quite unstable from time to time.

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