DITrack development

[Vlad Skvortsov]

Stefan Reichör wrote:

[skipped]

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

[skipped]

>> Comments?
>>     
>
> That looks good to me.
>   

Ok, opened i#162, scheduled to 0.7.

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

[skipped]

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

> I think I will use the svn version and send patches or ask for help
> when I need improved functionality on the ditrack side.
> I will start with #3, skip #2 and help to improve ditrack to use #1.
>   

Ok, cool.


[skipped]

>>> 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.
>>     
>
> That is needed for dt - isn't it?
>   

I was actually talking about dt-createdb here.

> You like to keep dt-createdb seperate. There are no classes used from
> the rest of ditrack yet.
>
> I still think it would be better to integrate dt-createdb as extra
> command to dt. But I have no problem with keeping it seperate.#
>   

Actually I had some thoughts about this separation some time back, and 
one of the reasons for keeping these separate is that we [ultimately] 
want to use Subversion Python bindings instead of command invocation. 
Thus, the 'svnadmin' functionality might not be available to DITrack 
client.

This is more of a gut feeling than any reasonable objection though. :-) 
So if you feel strong enough about merging dt with dt-createdb, the 
patches are welcome for discussion. :-)

> I propose to add a Backend.py file that serves as base for SVN.py and
> NullBackend.py
>   

Yep. Let me write up a text on backend assumptions first though. We need 
to clearly define what we expect of a backend to be DITrack-compatible. 
Opened i#163 as a reminder.

[skipped]
> First I suggest to change the invocation parameters for dt-createdb.
> Currently it uses:
>
>   
>> Syntax:
>>     dt-createdb <repository-url> <issue-db-dir> <local-wc>
>>  
>> The script non-recursively checks out <repository-url> into <local-wc> (which
>> should not exist), creates <issue-db-dir> there and schedules it for addition.
>>     
>
>
> I would drop the checkout part and assume that the issues should be
> added to an existing working copy. The checkout part can be done
> seperatly before - or we can supply these parameters by extra command
> line switches if we want.
>   

Agreed.

> So I suppose something like:
>
> dt-createdb <issue-db-dir> --backend svn
> dt-createdb <issue-db-dir> --backend none
> dt-createdb <issue-db-dir> --backend bzr
>
> I would add the needed code in dt-createdb to support these
> invocations.
>   

Since the backend type is going to be mandatory, I suggest dropping the 
'--backend' switch. Maybe we should make that parameter optional and 
default to 'none'.

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