Robert Butterfield wrote:
On Mar 21, 2006, at 6:18 AM, Christian Boos wrote:
A completely similar approach could be taken for the `repos`,
i.e. create it and attach it to the `req` upon the first call.
This would for example enable to solve the recent problem #2891
(Timeline slowness due to the use of get_repository) in a better
way.
...
-- Christian
With this layering would it be easier to consider multiple repos in a
single trac project?
Well, yes, this could probably scale to multiple repository support,
though it won't make it simpler.
For multiple repository support, some of the things to do are:
* find some coherent rules to refer to those repositories (both wiki and
url syntax)
* extend the db cache to handle multiple repos (and the resync command too)
* find a way to handle the 'meta' level, i.e. the "virtual" repository
which provides
access to all the repositories (to be used in the toplevel ''Browse
Source'',
or for viewing diffs between repositories)
Also, it /might/ be necessary to create a repos pool, for
performance reasons, at the env level.
Usually there would be a 'default' repos associated to a request
(e.g. when browsing a path inside a given repos), but one request
can also have to deal with different repositories (e.g. when
formatting a wiki text which refers to changesets belonging to
different repositories).
In any case, once a repos object is used by a client request,
it can remain associated to that request for its lifetime.
So the interface I proposed above (req.repos) should probably
be extended in order to support an optional repository name.
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
