distributed bug / wishlist tracking

Alexander Poddey alexander.poddey at gmx.net
Sat Jul 25 00:25:43 CDT 2009


Hallo again,
 
On my new job, I'm forced to use windows and we are not allowed to have 
servers running. We therefore introduced a distributed revision controlsystem 
(because it allows us to operate via shared directories).

I usually have several lists (bugs, todos, wihslists,...) in the source code 
and would like to apply the 'distributed stuff' idea to these files. I found 
be and ditz which - for my usecase - have several limitations (discussed in 
the following). I therefore would like to share my ideas about the ideal tool 
(for me) with you.
Does such a tool I'm thinking of already exists?
If not would this be useful for others too?
How do do it?

point 1:
the problem with be and ditz is, that it does not come in plain source code 
which I can compile to a binary. In principle, I'm not allowed to install 
perl, ruby, python, .... but I have a c++ and fortran compiler and I can use 
other open source code (in source form)
 
point 2:
be works quite well as commandline tool, which means I can submit a bug and 
comment, but from the command line. in my list-approach discussed above, i 
heavily use emacs (oh yes, I have emacs :lol: ) fancy copy and paste tools to 
shuffle infomarmations between individual items (which reside in the same 
file).

my approach would therefore be:

a tool which is written in c/c++ and is compiled before usage.
there should be several grouped lists (bugs, todo, feature, risks,...).
all the information is stored in small xml files in a tree structure which 
allows to browse and edit the data - in principle - via standard tools.
this 'database' might reside in any disptributed rev. controlled directory, 
e.g. a mercurial repositiory.
merge conflicts will only happen if exactly the same item or the same comment 
of an item is edited by mor than one person.

I like to keep things simple to see if they are really useful. therefore i 
would prefere a step by step approach as follows:
 
the tool could generate 'views' which are sorted and filtered compilations of 
the data. 
the views get generated on demand. the result are stored in one large file, 
which contains the data of interest in xml structure.
this file could then be edited with the favourite texteditor. after changes 
have been stored, the tool could extract the changes and write them back to 
the 'database'.

one could think of a profile which allows the user to define several views.
the tool could even start the favourite editor and write changes back 
automatically after the editor is closed....

resumee:
this approach allows to browse and edit combined lists (i.e. multi items per 
list) using standard tools.
the splitting of the lists in individual items - which prevents to much merge 
conflicts - is kept in background.
the combine/split operations could easily be coded using linked-list data 
processing codes (e.g. my libxml2f90 :wink: ).

i would most probably do this in c/c++
- which linked list code could I use?
- one could eventually use a part of the basic hg or git code for id 
generation
- how about poartability (file i/o, execution of 'command lines', e.g. the 
automatic start of the user preferred editor)?

what do you think?
does something like this already exist?
if not how would you start? 


 thx
alex

P.S: I posted this question in the debian forum yesterday (no responses yet).
http://forums.debian.net/viewtopic.php?f=3&t=42194
if this is to much offtopic here, we could switch discussion to there. 


More information about the Mercurial mailing list