Edgewall Software
Modify

Opened 4 years ago

Last modified 2 years ago

#9485 new defect

repository_sync_per_request seems to be ignored with multiple hg repositories

Reported by: vincent@… Owned by: cboos
Priority: normal Milestone: next-stable-1.0.x
Component: version control/changeset view Version: 0.12
Severity: normal Keywords:
Cc: leho@…, mmitar@…
Release Notes:
API Changes:

Description

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.

Attachments (0)

Change History (8)

comment:1 Changed 4 years ago by rblank

  • Resolution set to worksforme
  • Status changed from new to closed

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).

comment:2 follow-up: Changed 4 years ago by awagner@…

  • Resolution worksforme deleted
  • Status changed from closed to reopened

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?

comment:3 in reply to: ↑ 2 Changed 4 years ago by 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.

comment:4 follow-up: Changed 4 years ago by 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.

comment:5 Changed 4 years ago by lkraav <leho@…>

  • Cc leho@… added

comment:6 in reply to: ↑ 4 Changed 4 years ago by cboos

  • Component changed from plugin/mercurial to version control/changeset view
  • Milestone set to 0.13
  • Owner set to cboos
  • Status changed from reopened to new

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).

comment:7 Changed 3 years ago by Mitar

  • Cc mmitar@… added

comment:8 Changed 2 years ago by rblank

  • Milestone changed from 1.0 to 1.0-triage

Preparing for 1.0.

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as new The owner will remain cboos.
as The resolution will be set. Next status will be 'closed'.
The owner will be changed from cboos to anonymous. Next status will be 'assigned'.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.