DITrack development

[Stefan Reichör]

Vlad Skvortsov <vss at 73rus.com> writes:

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

That is the way I would prefer. It has also the advantage for ditrack
that ditrack is then fully scriptable.

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

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

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

Great :-)

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

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

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

Thanks for the hint. I have checked out a copy now. And I will monitor
the things that are going on until I find some time to contribute ;-)


Stefan.