= 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. [[br]]
   '' That's indeed the key usability point for such a system. 
   You wouldn't even want to attempt a merge of ticket data at the file level.
   Instead, the ui should present a way to merge changes, a bit similar to what is planned for resolving conflicts during concurrent edits.
   Have a look at the discussions in #2618, #4100 and #7145. #3006 is about merging different tickets in one, but I think it's also relevant to the topic.
   Conflict resolutions could even be done incrementally, saved on the non-default branch. When there are no conflicts anymore, the merge can proceed and the changes added by the branch will be available on the default branch, at which point the "cache" db can be updated (see next point). -- cboos''
 * 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.
   * Isn't it obvious?  Trac would still use a DB, only it wouldn't be the canonical source of info.  That would be that repository data.  The DB (and no, not in-memory, at least not default, depending on size of repo/mem of server machine) would be a kinda cache.
 * 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".
   '' That's probably the most visible reason about why it's not such a good idea to use the same repository for Trac itself. See the more in-depth discussion of this aspect in TighterSubversionIntegration. Nevertheless, as Trac makes progresses added MultipleRepositorySupport, it wouldn't be such a big deal to use a dedicated repository. -- cboos''


----
See also: #1465, #1132