On 17.08.2017 13:27, Peter Stuge wrote:
For background I started writing a new git backend for Trac based on
libgit2/pygit2 years ago, but didn't complete it because of the mismatch
between Trac repository datamodel requirements/expectations and the Git
data model. :\
My WIP is still at http://git.stuge.se/?p=trac.git;a=commitdiff;h=ea5437b
Are you aware of / do you have any thoughts on TracPygit2Plugin?
https://trac-hacks.org/wiki/TracPygit2Plugin
https://trac.edgewall.org/ticket/10606
Can anyone describe the purpose of persistent_cache and the
trade-offs with enabling it?
I am unsure, but the #11971 description mentions:
"1. The git connector constructs revisions cache for parents, children,
branches and tags. The construction is performed each request if
persistent_cache option is disabled. We could improve it."
I don't know Git or the Trac VCS model all that well. Just from reading
the source it seems that enabling the persistent_cache leads to storing
a reference to this (in-memory) revision cache in a Python class
variable (StorageFactory.__dict_nonweak).
Presumably the goal is to reuse that cache across requests to improve
performance.
So the trade-off would be better performance vs. higher memory usage
plus, as you pointed out, a higher risk for something to go wrong due to
the increased complexity.
Also it only helps if the same Python interpreter is used for another
request (not the case in e.g. CGI), right?
I'm not sure if it makes sense to use both this in-memory cache and
Trac's DB CachedRepository at the same time or if that's redundant and
pointless.
Any thoughts on that?
Peter
--
You received this message because you are subscribed to the Google Groups "Trac
Development" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to trac-dev+unsubscr...@googlegroups.com.
To post to this group, send email to trac-dev@googlegroups.com.
Visit this group at https://groups.google.com/group/trac-dev.
For more options, visit https://groups.google.com/d/optout.
