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.

[Pavel Shramov]

Post by Luke Kenneth Casson Leighton
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.

... skip ...

Post by Luke Kenneth Casson Leighton
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.

Current numbering scheme has disadvantages but it's simple and may be used
'inline' in mail, chat, etc... I think You won't write to somebody

"I've closed issue #c675522f-76ef-47a1-bb24-107ea83534eb" :)

Post by Luke Kenneth Casson Leighton
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
http://www.tuxmachines.org/node/23855
http://www.advogato.org/person/apenwarr/diary/371.html

I tried to use ditrack with git but problems with numbering You'd
mentioned above make this hybrid unusable.

P.S I'm not ditrack developer or expert or even advanced
user :)

[Luke Kenneth Casson Leighton]

Post by Pavel Shramov

Post by Luke Kenneth Casson Leighton
_after_ a commit, _then_ a nice unique ordered numbering
could be applied.

Current numbering scheme has disadvantages but it's simple and may be used
'inline' in mail, chat, etc... I think You won't write to somebody
"I've closed issue #c675522f-76ef-47a1-bb24-107ea83534eb" :)

precisely - that's why, _after_ a commit, the nice unique numbering
is applied. i've looked at the code a bit more closely, now: for comments,
a "local" numbering scheme is applied (with letters not numbers) then
after commit, this is turned into a "real" numbering scheme.

Post by Pavel Shramov

Post by Luke Kenneth Casson Leighton
basically, ditrack as it stands is perfect for a single user,

I tried to use ditrack with git but problems with numbering You'd
mentioned above make this hybrid unusable.

oo, how far did you get? send me what you have i'll see if i can
munge it a bit, later - i am pushed for time to get this email interface
going (on svn) first priority.

Post by Pavel Shramov
P.S I'm not ditrack developer or expert or even advanced
user :)

pffh, who is? :) sooooon become one, when you neeed something baad ha ha

[Vlad Skvortsov]

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

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.

Post by Luke Kenneth Casson Leighton
svn update repository/etc/newissue.txt
newissue = int(open("repository/etc/newissue.txt").read()) + 1
open("repository/etc/newissue.txt").write("%d" % newissue)
svn commit -m 'new issue number %d' % newissue
# 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.

Post by Luke Kenneth Casson Leighton
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.

Post by Luke Kenneth Casson Leighton
anyway have you seen git? it looks _far_ more interesting
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.

Post by Luke Kenneth Casson Leighton
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".
i'm not interested in single points of failure.
more later, gotta get coding!
l.
_______________________________________________
Dev mailing list
http://lists.ditrack.org/mailman/listinfo/dev