Edgewall Software
Modify

Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#10135 closed enhancement (duplicate)

Adding cached repository support to TracMercurial

Reported by: me@… 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 Christian Boos, 9 years ago

Resolution: duplicate
Status: newclosed

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.

comment:2 by anonymous, 9 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 lkraav <leho@…>, 9 years ago

Cc: leho@… added

comment:4 by Christian Boos, 9 years ago

Milestone: 0.12.3

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from (none) to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.