= Darcs specific cache =

For performance reasons, TracDarcs heavily relies on a specialized `CachedRepository` that basically reimplements the Subversion versioned tree for the tracked darcs repository: once a darcs changeset gets processed, the trac environment won't need to access the repository anymore (this is slightly simplified, as the ''content'' of each file at a given revision gets computed and cached only at its first request).

It does that by keeping a few extra tables (as of version 0.6, there are [http://progetti.arstecnica.it/trac%2Bdarcs/browser/tracdarcs/darcs-tables.sql four specific] `darcs_xxx` tables) extending/replacing the standard trac database schema. This is far from perfect, but it does the (''tricky''!) work reasonably well: all the merits goes to K.S.Sreeram who [http://progetti.arstecnica.it/trac%2Bdarcs/changeset/27 reimplemented the core] for version 0.4.

As I'm planning to implement MultipleRepositorySupport for 0.7, I'm trying to figure out a better integration with the standard schema, avoiding table/data duplication.

== Changesets ==

Generally speaking, in darcs the ''order'' of patches is meaningless: from an abstract point of view, a repository may be seen as a ''bag'' of changesets that, under the rules specified by the [http://en.wikibooks.org/wiki/Understanding_darcs/Patch_theory patch theory], may be composed (''commuted'') together to give the result one expects.

In the Trac context however it's very handy to be able to point to a particular change by it's ''application ordering index'' instead of the full hash. To accomplish that, TracDarcs chose to use an artificial monotonically incrementing index as a shortcut, effectively mimicing the Subversion view of the history.