> The Mercurial plugin recently adopted that approach as well > (http://trac.edgewall.org/changeset/8af21bda2b3e2272f4dc6b41037efcd896d2d5d8/mercurial-plugin/) > so I think it would make sense to do the same for Git.
I'll take a look at that. > Impressive! Yes, the pygit2 approach seems worth the trouble after all. I forked Peter's branch onto github[1] to start playing with it. Since it wasn't complete I ended up backing out his changes and reverting to trunk as of a few days ago. I've since split off a copy of PyGIT.py as PyGIT2.py (you can see this in some of my logs from #10826) but the only difference between those at the moment is that PyGIT2 imports pygit2 and does some additional logging. I'll try swapping out the internals of PyGIT.all_revs() with my pygit2 based version and maybe just keep the PyGIT API for the moment while I see where improvements can be made. I've been working on some code for walking the git repository as well (with some help from the fine folks on #libgit2 (freenode). But that takes about the same amount of time to execute as the trac-admin $ENV repository resync <repo> command... so no real improvement there. It may just be a problem of approach. And maybe it's not a huge deal if this is slow as long as the rest of the caching system is working. My underlying issue here seems to have been that apache/wsgi has been doing something funky that isn't at all like the correct behavior I'd expect. Ben [1] https://github.com/netjunki/trac-Pygit2 -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
