On Wed, May 03, 2006 at 12:25:16PM +0200, Christian Boos wrote: > Hi all, > > I think I've come up with a better way to manage the vc cache. > > As you know, we currently only store the information directly > needed for the TracChangeset component. > The TracBrowser part still needs to have direct access to the > repository and make use of the cache. > The proposed change would make it possible to implement the > `get_node()/get_entries()` methods in a generic an efficient way. > > More details here: > > http://projects.edgewall.com/trac/wiki/VcRefactoring#SupportforBigRepositories > > I have the feeling that this cached information can be used for > other needs as well: > * next/prev revision for a given path > * implement efficiently the revision graph view (#1445)
I can't really comment on the merits of your proposal, but I note you mention that "this should also work for mercurial". Shouldn't we be aiming for cross-VC backend caching as the primary goal? Or perhaps I have misunderstood? A generic VC caching system seems like very a worthy goal to me, as anything that simplifies the building of VC backends is going to help motivate developers provide new backends. > Also, I'd like to get some feedback about the possible choices > we have for handling multiple repositories: > > http://projects.edgewall.com/trac/wiki/VcRefactoring#SupportforMultipleRepositories Option one seems cleanest to me, with the proviso that you mention about performance. Option three would get my next vote. -- Evolution: Taking care of those too stupid to take care of themselves. _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
