Trac Site Updated to Trunk

24 February 2005

This tuesday, Daniel updated the Trac site to use the current trunk version of Trac. The main motivation behind the update was to get rid of availability problems. In the 0.8 release, we added persistent session support, which required a lot of write operations even on read requests… thereby pushing the underlying SQLite database into frequent lock-ups. You can read more about the problem on the mailing list thread “Sessions, SQLite and the infamous `Database is locked´ error”.

After a couple of initial hiccups, the new version is now in place and seems to be working pretty well. I have yet to encounter any downtime anyway, which had been pretty frequent before. So if you're using Trac and have been experiencing problems in this regard, you might want to consider switching to the development version as of revision 1277.

But apart from fixing the session performance, you'll also see some other notable improvements…

Overhauled custom query interface

The interface for building custom queries in 0.8 sucked. I'm the guy responsible for it, so I can say this. We wanted to get 0.8 out of the door at the time, and improving the query interface would have caused even more delay.

New query interfaceI'm proud of the new query interface though. It moves away from the Bugzilla heritage of separating the query form from the display of matching tickets. Instead both are always on the same page – meaning that when you see the results of the query, you also see the criteria. This approach only works because we don't show all available filters at once… instead, we only show the criteria that have been set. You can dynamically add/remove result filters without going back to the server as long as you have Javascript enabled. The whole thing still works without client-side scripting, but it's optimized for the common case where Javascript is available.

I'm planning a couple of improvements to queries before 0.9 gets released: time-related filters, greater-than/less-than match modes, and saving of queries. Last but not least, custom queries should probably become more prominent in the interface, they're kind of hidden away behind the reports right now.

In addition, I'd love to experiment with XMLHTTPRequest for updating the results display without refetching the entire page. Instead, only a compact representation of the tickets in Javascript (JSON-style) would be transferred, then nicely formatted as a HTML table on the client-side using the DOM.

Roadmap enhancementsMilestone scheduling improvements

Actually overdue since they became real entities in Trac, milestones now have separate due and completion dates. This means that you can schedule a milestone to be due on a certain day, and Trac won't automatically mark it as reached when that day arrives. Instead, it'll highlight the milestone as late, unless you've actually marked it as completed in the meantime.

A couple of things upcoming in the roadmap area:

  • Add an indication of assigned, "in-progress" tickets to the progress bars. Probably a yellow block in the middle.
  • Alert the user when she tries to mark a milestone with open tickets as completed. The alert should provide an option for retargeting associated tickets to a new milestone, similar to what we already have for milestone deletion.
  • Don't allow new or open tickets to be associated with a completed milestone.

Real support for copying and moving in Subversion

Thanks to a very nice patch by Christian Boos, Trac now detects when files are copied or moved in the subversion repository. Apart from just being more correct, this vastly improves the display of changesets when branching or tagging.

Support for conditional GET

Some of the more expensive pages now make use of ETags to support HTTP caching. The ETag is assembled from the last modified time of the resource, but also the user name and potentially session variables. I've written down the details in the mailing post “HTTP Caching in Trac 0.9”.

Stuff that's still in the Pipe

There's still some changes I would personally like to see in 0.9:

  • Switch to the python difflib module for generating diffs. For changesets, we currently rely on the subversion python bindings, which again rely on the good ole diff program being on the $PATH somehere. All in all, too fragile, and too expensive.

  • Database independence. Brad Anderson has been working on changes that would enable PostgreSQL support. I'd personally love to see those changes get in the next release.

  • Spam prevention. Probably a combination of IP-throttling, blacklisting and something similar to the MT-DSBL plugin.