Automatically launching a re-index or brute force search from browser requests needs to be configurable

[Patrick Martin]

In brief, being able to turnoff the auto-index behaviour for large and busy repositores would allow the post-commit script to handle the re-index, or a nightly task.

The update-index.py script is perfectly serviceable, and admins should have the option of only re-indexing using processes under their control, such as a cron job or Sheduled Task, to avoid a very large re-index from impacting apache's performance and stability.

A large re-index can blow the 2Gb address space, and thus never completes, which means once a repository has failed to index, it can never catch up. Being able to tune the re-index operations to ensure they succeed regularly would help mitigate this risk.

Tested against Trac and latest ReposSearchPlugin 0.10dev

[Alec Thomas]

I agree. I'll add a configuration option for this soon.

[anonymous]

That's great.

I have some more suggestions in the configuration front, but I'll raise a separate ticket, as they might be a little too cheeky.

[Alec Thomas]

(In [1881]) Not for the faint of heart, but if anybody wants to test the pyndexter branch it would be most useful to get some feedback.

You will need the refactoring branch of pyndexter, available from ​here.

More info in the README.

References #362, #371, #385 and #388.

[Ryan J Ollos]

Reassigning ticket after changing maintainer of plugin.

[Ryan J Ollos]

Sounds reasonable, but would only be implemented on the 0.11 branch.

[Ryan J Ollos]

Hello,

I took over maintainership of this plugin from athomas some time ago. There is a significant amount of work to do on this plugin, and I don't foresee having the time to do it all.

helend has written the TracSuposePlugin, which seems like a much better solution. Rather than writing the repository search functionality from scratch, a Trac interface to an existing repository search tool has been created. Rather than throwing more effort at this plugin, I'd prefer to help helend with enhancements to the TracSuposePlugin, or spend my time on other Trac plugin projects altogether.

I'd like to get some feedback and hear if anyone knows of a compelling reason to continue this project rather than moving to the TracSuposePlugin. Is there functionality in this plugin that doesn't exist in the TracSuposePlugin? I'm open to hearing all opinions and suggestions.

I'll leave these tickets open for about a week, but in all likelihood will close all of them and deprecate the plugin.

Thanks for your time,

• Ryan