Version 2 (modified by 15 years ago) ( diff ) | ,
---|
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 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 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 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.