CachedRepository support in TracMercurial

[asterix@…]

I used trac with svn, and switched to mercurial. the revision table in postgres is no more updated with new changesets. So when I do a search in changesets, new changesets are not listed. Did I forgot to configure something?

[Christian Boos]

No, I forgot to implement it ;-)

More seriously, TracMercurial works quite well now even for big repositories, without a cache.

However the cache would be needed for enabling the search in changesets and for getting faster and more accurate results for the timeline, so it's about time this gets implemented…

[miguel.araujo.perez@…]

I have developed a plugin called TracMercurialChangesetPlugin for fixing this issue. It allows you to sync revision table if you are using Mercurial. Then you can create a hook to keep it synced :) I hope it helps. I have mailed cboos about it, see If he can integrate into Trac-Mercurial.

​http://github.com/maraujop/TracMercurialChangesetPlugin

[bkocherov@…]

2miguel.araujo.perez

That do you think about use FULLHASH as 'rev' in opposite

NUMBER:SHORTHASH? I think only fullhash real unique. If repository very distributed then in different placess world changesets can be different NUMBER.

[Christian Boos]

#10135 was closed as duplicate.

[me@…]

I have implemented a naive version of MecrurialCachedRepository using a backward-traversing resync which overrides the default resync algorithm.

[me@…]

And this is the diff.

[me@…]

The above version is not complete yet. It's quick & dirty demo.

I'm inspecting its bug(?) that newly commited/pushed changesets are not synced correctly after the resync, as well as ticket commit updates.

[me@…]

Revised patch: applied the set diff algorithm by miguel.araujo.perez and now ticket commit updater works correctly

[me@…]

Diff for the revised patch

[me@…]

Revised again: error handling & branch display in the timeline

[me@…]

Diff for the revised patch

[Joongi Kim <me@…>]

The remaining issue:

• We need some efficient implementation like hg incoming/outgoing to find out which changesets should be synchronized. (The current "whole set comparison" would not scale well with very large repositories with more than 10k changesets.)

One mistake: must delete import pdb; pdb.set_trace() in line 744 of the patched backend.py before applying the patch to the trunk.

[Joongi Kim <me@…>]

Another idea:

• Currently CachedRepository only have one sync() method which is called by both 'resync' and 'commit ticket updater'. For the latter case, we can use hints from the commit ticket updater to determine which revisions should be synchronized since they are given as the command line arguments. We do not have to the same thing twice. We could add optional arguments to sync() method to handle it.

[Ryan J Ollos]

#9485 closed as a duplicate.

[anonymous]

Replying to lkraav <leho@…>:

Can you pls tell where / how to use this patch, as it is still not working in the latest TracMercurial?

Thanks

[anonymous]

Replying to me@…:

The above version is not complete yet. It's quick & dirty demo.

I'm inspecting its bug(?) that newly commited/pushed changesets are not synced correctly after the resync, as well as ticket commit updates.

Can you pls tell where / how to use this patch, as it is still not working in the latest TracMercurial?

Also, how to trigger the initial caching once this file is patched?

Thanks