starting to use ditrack - dev roadmap

[Luke Kenneth Casson Leighton]

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

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

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

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.