#10135 closed enhancement (duplicate)
Adding cached repository support to TracMercurial
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | plugin/mercurial | Version: | 0.12.2 |
Severity: | normal | Keywords: | |
Cc: | leho@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description
I'm using TracMercurial with a fairly large repository which contains a few hundreds revisions including Linux kernel. It works well, but the only painful point is seeing the timeline. It takes more than 10~15 seconds to load.
I have inspected what the problem is, and noticed that the current TracMercurial plugin does not implement cached repository, though it is scheduled for the future. I know that, and the intention of this ticket is to inform you some considerations when you continue on it. (Maybe you smart guys know this problem already. :)
Anyway I tried to implement it by myself, and noticed that the database schema of Trac itself must be changed to handle "merge changeset"s correctly.
In the mercurial plugin, MercurialChangeset class has the method get_changes
. It retrieves the modified/deleted/added files in a changeset and they are used in resync process in Trac's repository cache.
Let's suppose there is a changeset 10, which is a merge changeset of 8 with file a, b, c and 9 with file b. In the changeset 10, get_changes
returns the file b twice, and causes IntegrityError when resync.
One possible workaround is to limit the number of same files returned in get_changes
to 1, e.g.) edits = edits[:1]
.
But, ultimately, Trac's database schema should be able to handle such cases by adding 'parent changeset' into the primary keys of its revisions
table.
Attachments (0)
Change History (4)
comment:1 by , 14 years ago
Resolution: | → duplicate |
---|---|
Status: | new → closed |
comment:2 by , 14 years ago
Thanks, and I found another problem. ;-)
Trac's cached repository resync method assumes there is only one "youngest changeset" (aka head) so that it drops several changesets which are not the ancestor of the picked head. It may be implemented as revision_link
table as mentioned in VcRefactoring, or some other general models.
comment:3 by , 14 years ago
Cc: | added |
---|
comment:4 by , 14 years ago
Milestone: | 0.12.3 |
---|
Please have a look at #8417. I very much appreciate that you tried to implement it and in fact you're even quite welcome to push your efforts further ;-)
If the table needs to be changed, so be it, you can add an upgrade step for the database model. Also have a look at my previous idea in VcRefactoring#NewRepositoryCache and maybe we could sketch a new table design in VcCache were I've already sketched the prerequisites.