From seanerussell at gmail.com Tue Jan 26 09:55:13 2010 From: seanerussell at gmail.com (Sean Russell) Date: Tue, 26 Jan 2010 09:55:13 -0500 Subject: [ditz-talk] Ditz/Trac synchronization plugin Message-ID: Attached is the beginning of a sync plugin for Trac. I'm trying to get out of the house and get to work at the moment, but I'll post a Trac URL for the project later this week. For now, if anybody is interested in testing or working on it, here's a partially functioning start. It requires trac4r and ditz, but nothing else. It also assumes that you installed trac4r with rubygems. Right now, it *only* does one-way syncing from Trac to Ditz. Going the other direction won't be any more difficult; I just haven't gotten to it yet. Usage: first, save attachment to wherever your ditz plugins live; eg, /usr/local/lib/site-ruby/1.8/ditz/plugins. Then: ditz reconfigure # Only the first time ditz sync # yeah, yeah... overlaps with the git plugin. The 'ditz reconfigure' allows you to set the Trac URL of the project (without the login/xmlrpc stuff), and the uid and password for a user that has XMLRPC permissions in Trac There are a *lot* of caveats to this: 1. Work with a *clone* of your repository to start with. I do not guarantee that this is bug-free. 2. Not everything between ditz and Trac map 1-1. I had to make some assumptions about how to map statuses and dispositions -- most of these assumptions are in the mappings at the top of the plugin. Suggestions about better mappings are welcome. 3. I'm planning on extending the ditz Issues to include some of the information from Trac; in particular, the plugin matches issues by the Trac:summary / ditz:title, which is guaranteed to fail in not-to-unusual edge cases, so I'm going to store the Trac ID in the ditz issue. 4. Related to the previous two points is that some Trac information isn't saved in ditz, such as priority or severity. I'll add support for these, but some information -- such as attachments -- I probably won't. 5. Because of limitations in ditz's configuration system (specifically, there isn't per-repo configuration), you can only use this with a single project. That is, the configuration is global, not per repo. I may have to implement a plugin-specific configuration mechanism to fix this. 6. It is very verbose right now. I need to add a --debug mode to reduce that. Oh, and the code is not particularly pretty, nor well documented. OTOH, it isn't very complex, either. However, it seems to work fairly well, although testing has so far been very limited. Please, please, make sure that XMLRPC is working *outside* of this plugin before submitting issues about it. And don't bother asking me about how to configure Trac to get XMLRPC working -- it was a pain in the ass for me to get it working on my site, and I'm not eager to go through that again. I'm not even sure what I did that made it work, so I'd probably just screw up your Trac configuration. Feedback is welcome. Assistance is welcome even more. Cheers, --- SER -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: trac-sync.rb Type: application/x-ruby Size: 9331 bytes Desc: not available URL: From seanerussell at gmail.com Tue Jan 26 22:17:30 2010 From: seanerussell at gmail.com (Sean Russell) Date: Tue, 26 Jan 2010 22:17:30 -0500 Subject: [ditz-talk] ditz-trac Message-ID: There's now a Trac page for the Trac synchronization plug-in project, as well as a publically accessible (read-only) Mercurial repository: http://trac.germane-software.com/ditz-trac http://hg.germane-software.com/ditz-trac --- SER -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanerussell at gmail.com Wed Jan 27 22:44:28 2010 From: seanerussell at gmail.com (Sean Russell) Date: Wed, 27 Jan 2010 22:44:28 -0500 Subject: [ditz-talk] ditz-trac update Message-ID: So, there are new versions out. However, I'd suggest not using the tip version; pull r5, if you use it at all. There's a problem with how Trac change log and ditz log events are identified, and a more serious problem stemming from the fact that the Trac change log time stamps are not controllable through XMLRPC, which can lead to ditz issue log events being duplicated. r5 doesn't have this problem, because it's ditz -> Trac syncing is limited to creating tickets, milestones, and components -- it doesn't sync the change logs (in that direction) yet. --- SER -------------- next part -------------- An HTML attachment was scrubbed... URL: From seanerussell at gmail.com Sat Jan 30 18:34:59 2010 From: seanerussell at gmail.com (Sean Russell) Date: Sat, 30 Jan 2010 18:34:59 -0500 Subject: [ditz-talk] ditz-trac update #2 Message-ID: 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 the comments. - 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. Cheers, --- SER -------------- next part -------------- An HTML attachment was scrubbed... URL: From wmorgan-ditz at masanjin.net Sun Jan 31 10:21:58 2010 From: wmorgan-ditz at masanjin.net (William Morgan) Date: Sun, 31 Jan 2010 10:21:58 -0500 Subject: [ditz-talk] ditz-trac update #2 In-Reply-To: References: Message-ID: <1264950854-sup-3529@masanjin.net> Reformatted excerpts from Sean Russell's message of 2010-01-30: > 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. Wow, thanks! I am pretty happy with how the plugin stuff turned out in Ditz. Thanks for ploughing through the lack of remaining support community, and keep us informed about the plugin! -- William From seanerussell at gmail.com Sun Jan 31 12:11:07 2010 From: seanerussell at gmail.com (Sean Russell) Date: Sun, 31 Jan 2010 12:11:07 -0500 Subject: [ditz-talk] ditz-trac update #2 In-Reply-To: <1264950854-sup-3529@masanjin.net> References: <1264950854-sup-3529@masanjin.net> Message-ID: I've half a mind to fork it and make some additions that fit it better with my habits (more command-line alternatives to the interactive stuff)... but only half a mind. I've enough open source projects that I don't have enough time to work on, as it is. Out of curiosity, how many people offer you patches? If it were just a matter of release management, I might be able to manage a fork, with my occasional tweak, reviewing patches, and the occasional release... but if the fork depends entirely on my development effort, then it probably isn't worth it, since the updates would be extremely rare. Is there *anybody* on this list, besides myself, who has both interest and skill to respond to bug reports and do modest development? If so, please contact me. Also, since I value your opinion on these matters, William -- what are you using now for issue management, and why? I ask, because I'm considering whether some sort of direct offline Trac tool might be lower cost for me. I like ditz just fine, but I'm not sure that I need my issue tracker to be version controllable -- I just need it to be off-line-able, and have a separate DB per project. In fact, I'm increasingly convinced from what I've seen that software developers have no more -- and possibly less -- than a 50% stake in issue management; users have the other solid 50%. As for ease-of-use, ditz-like trackers have a split more like 95/5; web-based trackers split it more 80/20. The more I think about it, the more I believe that a solid web tracker which can be used off-line and sync'ed is the ideal design. Trac, or Redmine, or some such. My experience with ditz-trac has shown me that the XMLRPC interface to Trac simply isn't sufficient for a robust off-line sync'ing. It imposes too many limitations on the event log. What I really need is direct write access to the Trac DB, so that I can manage the events with finer resolution. If I go down that path, though, then one wonders whether it might not be better to simply copy the sqlite DB, rather than trying to shoe-horn the two differing schemas (Trac/ditz) together. Well, thanks for responding, William. --- SER On Sun, Jan 31, 2010 at 10:21 AM, William Morgan wrote: > Reformatted excerpts from Sean Russell's message of 2010-01-30: > > 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. > > Wow, thanks! I am pretty happy with how the plugin stuff turned out in > Ditz. Thanks for ploughing through the lack of remaining support > community, and keep us informed about the plugin! > -- > William > _______________________________________________ > ditz-talk mailing list > ditz-talk at rubyforge.org > http://rubyforge.org/mailman/listinfo/ditz-talk > -------------- next part -------------- An HTML attachment was scrubbed... URL: