RjOllos wrote: > I've been wondering about the purpose of [git] persistent_cache and what > the trade-offs are with enabling it. I've looked through the code, but > don't have a clear idea yet.
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 I don't exactly remember what persistent_cache does, but can talk about those data model incompatibilities, because I think they are the purpose for caching. Trac wants to look up all previous *and* all later commits relative to a given commit in a repository, while the Git data model only stores previous commits. Traversing commit history in reverse chronological order is quite efficient in the Git data model, forward not so much. So "later commits" can only be looked up efficiently if Trac caches which commits are followed by which other commits, and that cache must be updated with every new commit added (or removed!) in the repository. If you don't know the id of the new commit then you have to resync, ie. scan all commits, which takes a long time for larger repos. > once properly configured a cached repository is always preferred as > it will offer better performance ...mmmhh.. Only if the cache is always reliably updated! If there is ever a single lapse then Trac gets stuck at that point, until manual resync. > 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." > Would it make sense to have persistent_cache as a per-repository > attribute, as in #12406? I think it would, since the persistent cache is much more fragile. It could be desirable to enable it selectively. > Similarly, should git_fs_encoding be a per-repository attribute? Clear yes on this one. One Trac instance may be serving many repos for a team working in very different environments, where one repo uses a special encoding. It would be super annoying to require a separate Trac instance for that one repo. Or worse, if there are many repos with different encodings - though I think that's less likely. Maybe #11164 is also related to persistent_cache? #11164: https://trac.edgewall.org/ticket/11164 #11971: https://trac.edgewall.org/ticket/11971 Thanks for your work on Trac. Hope I could help a bit. //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.
