Christian Boos wrote: >> IMO the current PyGIT isn't really suitable for a 1.0 release. :) > > Well, we can label the git support as "experimental"
Please include a prominent note about the moderate performance, and/or mention that PyGIT works by forking and execing many git processes per web request. >> I've started work on a pygit2 based replacement > > I'd be happy to have a look, and experiment a bit. http://git.stuge.se/?p=trac.git > instructions about how to set up the dependencies would be a good start http://libgit2.github.com/ https://github.com/libgit2/pygit2 They have no further dependencies. Both are possibly packaged in your favorite distribution already. If you use Gentoo you can run layman -a stuge && \ echo -e 'dev-libs/libgit2 **\ndev-python/pygit2 **' >> \ /etc/portage/package.keywords && \ emerge =dev-libs/libgit2-9999 =dev-python/pygit2-9999 to get live ebuilds. > (as well as the TracDev/Performance/Git page I mentioned in #10594). As I wrote I think it's way premature to do any Git-specific performance discussion as long as PyGIT is still used. >> It would be very nice to have it included at least as an alternative. > > Sure, but that will have to wait for whichever Trac 1.1.x or 1.3.x > release will be current when this effort is ready. Fair enough! >> The get_youngest_rev(), previous_rev() and child_revs() Repository >> operations are very very expensive; they require traversing the >> entire commit graph! > > That was pretty much my point in our little discussion in #10594. > I'm not convinced that simply switching the way we use git (command-line > vs. library bindings) will be enough to address the performance issues; You know that fork and exec are expensive, right? It's not cool to have web software work like this in 2012. It was halfway OK in 1995, but not anymore. :) Also, "simply" is downplaying PyGIT. Because it uses git commands it remains limited to what git commands can do, where the Git data model isn't very well exposed, nor in a manner which is very useful. It's all sorts of wrong. > it's rather rethinking carefully how to access the information, when > and what to cache, etc. I very much welcome this effort to review the Trac Repository data model! But I have zero expectation that it will result in substantial code changes within say the next few months. Native repo access is on the other hand a bite sized problem, and will certainly have noticeable impact on performance. Hopefully you and others will turn the Repository interface inside out in parallel with pygit2 work, to get even more out of Trac in the end! :) //Peter -- You received this message because you are subscribed to the Google Groups "Trac Development" group. To post to this group, send email to trac-dev@googlegroups.com. To unsubscribe from this group, send email to trac-dev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en.
