[ditz-talk] ditz-trac update #2
seanerussell at gmail.com
Sat Jan 30 18:34:59 EST 2010
I think the plugin is ready for "first release" status, so here it is.
- It syncs bi-directionally, but the value here is mostly in the ticket
status. It syncs comments as well, but state change logs/history is *not
* synced. This is primarily because there's no way to force Trac to
store a change event with a specific date, meaning that there's no control
over the order of history. This makes resolving differences in the event
log practically impossible. So, ditz-trac just syncs the ticket status and
- It now has a reasonable amount of debugging done. You will confuse it
if you try to sync branches of ditz to a single Trac instance -- confuse,
and pollute your Trac DB with duplicate tickets. It tries to be smart, but
there's no really good solution here that I can think of. I'm not sure
whether it'd be of much use, anyway. I may eventually add branch support
with custom Trac fields, but... that's so far down the road I'm not sure
it'll ever happen.
- Trac's XMLRPC interface has some curious limitations and quirks that
really limit what can be done with a tool like this. And it can be annoying
to work with; for instance, it took me a long time to figure out that *
ticket.query()* results are (a) sorted by whatever default sort is set up
in Trac, which appears to be priority, and (b) limited by the Trac web
page's "100 results per page" setting. This means that there's no foolproof
way to figure out exactly how many results there are in the DB except by
trial and error ("max=100; Fetch maxresults; did I get exactly max results?
If yes, max*=2, and repeat"). I have to admit, the plugin doesn't
implement the aforementioned algorithm. I just set the max to 1,000,000
results. If you have more than 1,000,000 tickets, then you're probably
going to need something more sophisticated than this little hack.
Right now, it accomplishes what I want it to. However, it has made me
realize that if I really want to sync with Trac, I'm basically going to have
to dispense with the XMLRPC interface and go directly to SQL access, and if
I can do that, well... it might be worth exploring another approach to
offline, yet sync'able, ticket management.
It was worth the effort; William has obviously either worked with plugin
infrastructures before, or he's a plugin prodigy... the interface is
extremely complete and easy to use, and it's taught me a lot about the
domain. If you haven't played with plugin development, I recommend it as a
study in good plugin architecture design.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ditz-talk