Edgewall Software
Modify

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#10759 closed defect (fixed)

CachedRepository doesn't cache non-latest changesets after caching latest changeset

Reported by: Jun Omae Owned by: Jun Omae
Priority: high Milestone: 0.12.4
Component: version control Version: 0.12
Severity: normal Keywords: git cache
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

CachedRepository caches newer changesets than youngest_rev in metadata. In subversion, a committed changeset is always newer than the cached changesets and will be cached. However, in Git, a pushed change is not always newer and will not be cached….

Reproduce

  1. Setup Trac 0.12-stable with git-plugin (or 1.0dev with tracopt.git)
  2. Setup git://github.com/jun66j5/trac-git-cache.git
    jun66j5@gotanda:1672$ git log --all --oneline --graph
    * 9f5e555 [master] third
    | * 97cbb3c [dev] second
    |/
    * 57fa298 [master] first
    
  3. Push master branch. 57fa298 and 9f5e555 will be cached.
  4. Push dev branch. 97cbb3c will NOT be cached.

Workaournd

If the changeset is not cached at CachedRepository.sync_changeset(rev), creates revision and node_change records.

repos:jomae.git:ticket10759/creating-cache-on-sync/0.12

Attachments (0)

Change History (9)

comment:1 by Jun Omae, 8 years ago

Milestone: next-minor-0.12.xnext-stable-1.0.x

comment:2 by Christian Boos, 8 years ago

This is somehow related to the changeset hook ticket #10730: we could probably try to detect all what's new since last time, starting from all the refs, but better do that proactively by using hooks and then update the cache when changes are pushed in (or "deleted").

Now about the proposed workaround, it looks OK but would probably benefit from a little refactoring (I'll follow-up on this).

Last edited 8 years ago by Christian Boos (previous) (diff)

comment:4 by Christian Boos, 8 years ago

Jun, did you have the chance to validate my follow-up?

comment:5 by Christian Boos, 8 years ago

Also, it's a change on 0.12-stable, so is there a reason why you thought that to be too risky for 0.12.4? I'd be OK with 0.12.4, provided a few more testing.

in reply to:  5 comment:6 by Jun Omae, 8 years ago

Milestone: next-stable-1.0.x0.12.4

Jun, did you have the chance to validate my follow-up?

Looks good, Thanks.

Also, it's a change on 0.12-stable, so is there a reason why you thought that to be too risky for 0.12.4? I'd be OK with 0.12.4, provided a few more testing.

No reason, however, I think that there is a little risk.

I want to push to 0.12.4 and I'll provide unit tests for the changes to avoid the risk.

comment:7 by Christian Boos, 8 years ago

Tested [f83d4173/jomae.git] and [0f7cb3b5/jomae.git]. Works fine!

comment:8 by Jun Omae, 8 years ago

Resolution: fixed
Status: newclosed

Applied in [11159] and [11160]. Thanks for the follow-ups, Christian!

comment:9 by Jun Omae, 8 years ago

Owner: set to Jun Omae

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Jun Omae.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Jun Omae 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.