repository_sync_per_request seems to be ignored with multiple hg repositories

[vincent@…]

I have Trac 0.12 running. Four Mercurial repositories are configured:

[repositories]
.alias = suave
.hidden = true
suave.description = This is the ''main'' project repository.
suave.dir = /var/lib/hg/suave
suave.type = hg
suave.url = http://smooth.applied-tactical.org/hg/suave
m3django.description = m3-django
m3django.dir = /var/lib/hg/m3-django
m3django.type = hg
m3django.url = http://smooth.applied-tactical.org/hg/m3-django
butane.description = butane
butane.dir = /var/lib/hg/butane
butane.type = hg
butane.url = http://smooth.applied-tactical.org/hg/butane
environments.description = django-environments
environments.dir = /var/lib/hg/django-environments
environments.type = hg
environments.url = http://smooth.applied-tactical.org/hg/django-environments

No commit hooks or other hooks are set up. Any commit done on any of the repositories shows up immediately in the timeline. This behavior is the same with the following settings:

• repository_sync_per_request not mentioned at all
• repository_sync_per_request = foobar
• repository_sync_per_request = butane, suave

Adding a new repository also doesn't require django-admin resync, its changes appear instantaneously in the timeline. If this is intended, it should definitely be documented.

[rblank]

Yes, this is due to the fact that the Mercurial plugin doesn't cache the changeset metadata in the database, so the sync() operation is a no-op and any change to the repository is directly visible in Trac.

We don't really want to advertise this, as it may change in a future version of the plugin. And actually, the same applies if you configure a Subversion repository with the type direct-svnfs, where no caching is done (but performance is bad).

[awagner@…]

Would this cause TracSearch for changesets to come up empty since nothing is cached?

I have numerous mercurial repositories (no hooks) and when I look in the sqlite db I've got an empty revision table.

Is this by design? Should I add hooks to all 100+ repos? Should this be a new defect ticket? Any advice?

[cboos]

Replying to awagner@…:

Should this be a new defect ticket? Any advice?

This is #8417.

Should I add hooks to all 100+ repos?

Yes, once #8417 is implemented.

[rblank]

Yes, search functionality requires caching, so searching currently doesn't work with Mercurial. It's not by design, it's only because it hasn't been implemented yet for that backend.

Adding hooks for Mercurial repositories still makes sense if you have plugins that use the repository change listener functionality, like the TicketCommitUpdater.

[cboos]

Replying to rblank:

Yes, search functionality requires caching, so searching currently doesn't work with Mercurial.

And as such, moving the changeset search provider to cache.py is one TODO.

Reusing this ticket for that, as otherwise it's a duplicate of #8417 (unless I missed something).

[rblank]

Preparing for 1.0.

[rjollos]

Closing as a duplicate of #8417. Ticket #12068 has been created to address comment:6.

[rjollos]

Replying to rjollos:

Ticket #12068 has been created to address comment:6.

But turns out #10764 already exists to address comment:6.