[Trac-dev] Improving next_rev for scoped svn paths

Hi all,

We've had a number of tickets related to either silly memory growth  
or slow performance on scoped svn repositories (in particular,  
#5213).  This is a big issue for everyone since the same code paths  
are taken for restricted changesets (which search engines will index,  
even if your users don't click on them).

I saw this happen for one big user of Trac and tracked down that the  
cached repository isn't using a cached representation of next_rev.   
I'd like review of the following patch, which improves the situation  
bigtime on my system.  In particular, I'm not aware of any backends  
using CachedRepository other than svn, which uses numeric revs  
(please correct me if wrong).

normal changeset: 0.25s
restricted changeset: 12s
restricted w/ cached next_rev: 0.6s

Tim

--~--~---------~--~----~------------~-------~--~----~
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 <at> googlegroups.com
To unsubscribe from this group, send email to trac-dev-unsubscribe <at> googlegroups.com
For more options, visit this group at http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---