starting to use ditrack - dev roadmap

[Vlad Skvortsov]

Luke Kenneth Casson Leighton wrote:
> hi guys,
> just to let you know that i'm planning to use ditrack, because it's
> 1) python 2) beautiful 3) dead frickin simple.
> plans include an email interface. i already have "new" working,
> and i'll have "add comment" this afternoon.
> i have a couple of issues that need to be resolved - one of them
> is that any changes can result in conflict - there's no race-condition
> checking on creation of new issues, creation of new comments, etc.
>   

Ultimately the serialization of updates to the database is to be done on 
the server side (e.g. by Subversion server currently). The client-side 
conflicts which would happen because of this need to be properly handled 
and it's one of the must-fix items for 1.0.

> a solution is to do spin-lock using the svn repository:
>
> while 1:
>    svn update repository/etc/newissue.txt
>    newissue = int(open("repository/etc/newissue.txt").read()) + 1
>    open("repository/etc/newissue.txt").write("%d" % newissue)
>    try:
>      svn commit -m 'new issue number %d' % newissue
>    except:
>      # remove from local repository, ready for update on next loop.
>      # eventually this will work.
>      rm "repository/etc/newissue.txt"
>      continue
>    break
>
> obviously, this can't be done in an offline situation: under
> such circumstances, #1 #2 #3 etc. etc. isn't good enough,
> you'd need to prefix by username or some other unique
> identifier, or have random numbering large enough to not
> have conflicts.
>
> _after_ a commit, _then_ a nice unique ordered numbering
> could be applied.
>   

We have "local" entity names specifically for working off-line.

> basically, ditrack as it stands is perfect for a single user,
> and.... i'm not planning on using it as a single user system.
>   

Well, we use it for self-hosting for quite a while now, so it can serve 
well for a small team of developers. There are issues that have to be 
addressed before 1.0 (concurrent access is one of them), but it works 
pretty good in 90% of real-life situations. And for the remaining 10% 
you can usually fix things manually. :-)

I know that it's been used in production at some small companies.

> anyway have you seen git? it looks _far_ more interesting
> than svn as a back-end:
> http://www.tuxmachines.org/node/23855
> http://www.advogato.org/person/apenwarr/diary/371.html
>   

The choice of the backend is primarily dictated by the following 3 factors:
1) it is mainstream now, with plenty of hosting services offering SVN;
2) it is easily comprehensible;
3) we use it ourselves.

We are not ideologically opposed to other kinds of backends, but given 
limited resources we have, we focus the development on what we perceive 
is the most important thing to support.

> btw if you're curious as to why i'm interested in ditrack instead
> of the one that is used for bugs.python.org it's because
> ditrack is so damn small and it has the word "distributed".
> the tracker on bugs.python.org is targetted as a web service:
> i'm not interested in single points of failure.
>
> more later, gotta get coding!
>
> l.
> _______________________________________________
> Dev mailing list
> Dev at lists.ditrack.org
> http://lists.ditrack.org/mailman/listinfo/dev
>   


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