On 6/4/2012 10:53 AM, Peter Stuge wrote:
Christian Boos wrote:
One big reorganization that I think would still be important to do even
before the beta1 is the move of the svn support to tracopt. Now that we
have Git support there, there's no reason to keep svn directly in
trac/versioncontrol (see [2]). I think we can leave around a few
imports for backward compatibility. I created #10712 for that.
IMO the current PyGIT isn't really suitable for a 1.0 release. :)
Well, we can label the git support as "experimental", like we did for
the Mercurial support until it got improved to the point it is now able
to handle huge repositories reasonably well. Note that you'll get
similar performance issues for big Subversion repositories, as our svn
support is also not lightning fast... This, as well as the numerous
other known performance weak points (*) won't prevent us to make a 1.0
release, as we're mainly doing it 1) for having a fresh start for a new
release schedule (i.e. doing regular releases for both maintenance and
development branches) and 2) to acknowledge the fact that after many
years of continuous improvement, it's now more than reasonably stable
and solid. We don't use 1.0 to mean it's perfect on all accounts (that
will be 2.0! ;-) ).
I've started work on a pygit2 based replacement, but am in the middle
of an interrupt storm at the moment, keeping me busy elsewhere. I'd
be happy if someone else wants to also work with this.
I'd be happy to have a look, and experiment a bit. A fork and a few
instructions about how to set up the dependencies would be a good start
(as well as the TracDev/Performance/Git page I mentioned in #10594).
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.
Also, while doing this, I've understood just how badly the Git data
model fits into Trac's Repository data model. :\
True.
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;
it's rather rethinking carefully how to access the information, when and
what to cache, etc.
-- Christian
(*) http://trac.edgewall.org/wiki/TracDev/Performance
--
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.
