On 01.06.2013 19:05, W. Martin Borgert wrote: > I'm trying to integrate a Git repository into Trac. For testing I > chose the Linux kernel (~375000 commits, ~1.3 GB). I first tried > without any special settings in trac.conf. Unfortunately the "Browse > Source" view was unusable slow. Than I tried the setting with:
Is your real repository the same size? Have you tried testing it with a repository size more similar to your real needs? If your repository is of a more typical size it will work okish. > [git] > cached_repository = true > persistent_cache = true It will display wrong results (unless it was fixed, but I don't think so). > On 2013-06-01 09:29, RjOllos wrote: >> I just started working with the Git connector component as well, and >> noticed on the Git documentation page [1]: "Please note that we're still >> considering the level of performance to be sub-optimal, so it might not >> work for you. Small to medium sized repositories should be handled >> reasonably well, however." > > OK. I see, that there are some open tickets and ideas on > improvements, e.g. #10606. > > Is there any reason (not) to use libgit2/pygit2? Would this > improve performance anyway? >From what I remember reading the code some time ago - it won't. Performance problems (and wrong data with cache) are a result of Trac version control system being tightly dependant on the SVN model. GitCachedRepository is using an SVN cache, and its representation assumes linear (:D) order of commits. IMO without huge rewrite of GitCachedRepository and probably some parts of the not-cached version no gains can be achieved. -- silk -- You received this message because you are subscribed to the Google Groups "Trac Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/trac-users?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
