Distributed Trac

This is an open forum of thoughts for using Trac in a distributed fashion, though it would work equally well in a centralized environment.

Assume a backend where Trac data is versioned, potentially in the very same repository as the code Trac is managing. Given this, checking out the repository gives you a snapshot of the state of the project: code, bugs, wiki documentation, attachments, et cetera. You could edit the files in the repository by hand, though it would likely be far more convenient to just run tracd with that data, giving a local interface. You can make your code changes, modify the bug statuses for those changes, update documentation, and commit everything at once.

In a centralized system this would push back up so everyone can see the changes. Or you could skip editing the local Trac copy and just use a public central site, just like how it is done today.

With a distributed VCS in charge of Trac data though, you can work offline, send changes of all project data to teammates or to a integration manager to test everything before making the changes public. I envision this being an extremely powerful workflow.

Hurdles of Distributed Trac

• Merging data could get complicated. If the backend is designed well though, it shouldn't be too bad.
• Searching through files would be slower than a database.
  • The trac server could create a temporary database from the versioned data. An SQLite memory db could work well for this.
    • It would be really slick if it could recognize when the data has changed and just update an existing import instead of redoing the entire set.
• Trac data commits could clutter the VCS log making it difficult to find the important code changes amongst many revisions of "Page X changed by Y".