Opened 15 years ago
Last modified 2 years ago
#8417 new enhancement
CachedRepository support in TracMercurial
Reported by: | Owned by: | Christian Boos | |
---|---|---|---|
Priority: | high | Milestone: | plugin - mercurial |
Component: | plugin/mercurial | Version: | 0.11.1 |
Severity: | major | Keywords: | mercurial changeset patch |
Cc: | awagner@…, richard.liao.i@…, bkocherov@…, miguel.araujo.perez@…, ismael@…, macke@…, me@…, leho@…, dev@…, mmitar@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
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?
Attachments (6)
Change History (29)
comment:1 by , 15 years ago
Milestone: | → not applicable |
---|---|
Priority: | normal → high |
Severity: | normal → major |
comment:2 by , 15 years ago
Summary: | revision table not updated → CachedRepository support in TracMercurial |
---|
comment:3 by , 15 years ago
Milestone: | not applicable → mercurial-plugin |
---|---|
Severity: | major → critical |
comment:4 by , 14 years ago
Cc: | added |
---|
comment:5 by , 14 years ago
Cc: | added |
---|
comment:6 by , 14 years ago
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.
comment:7 by , 14 years ago
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.
comment:8 by , 14 years ago
Cc: | added |
---|
comment:9 by , 14 years ago
Cc: | added |
---|
comment:10 by , 14 years ago
Cc: | added |
---|
comment:11 by , 14 years ago
Cc: | added |
---|
by , 13 years ago
Attachment: | backend.py added |
---|
I have implemented a naive version of MecrurialCachedRepository using a backward-traversing resync which overrides the default resync algorithm.
follow-up: 23 comment:13 by , 13 years ago
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.
by , 13 years ago
Attachment: | backend.2.py added |
---|
Revised patch: applied the set diff algorithm by miguel.araujo.perez and now ticket commit updater works correctly
by , 13 years ago
Attachment: | backend.3.py added |
---|
Revised again: error handling & branch display in the timeline
follow-up: 22 comment:14 by , 13 years ago
Cc: | added |
---|
comment:15 by , 13 years ago
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.
comment:16 by , 13 years ago
Another idea:
- Currently
CachedRepository
only have onesync()
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 tosync()
method to handle it.
comment:17 by , 11 years ago
Cc: | added |
---|
comment:19 by , 9 years ago
Cc: | added |
---|
comment:20 by , 9 years ago
Type: | defect → enhancement |
---|
comment:21 by , 9 years ago
Keywords: | patch added |
---|---|
Severity: | critical → major |
comment:22 by , 6 years ago
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
comment:23 by , 6 years ago
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
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…