New changesets only show up on reload

[Manuzhai]

When I commit a new changeset to my repository, then browse to the timeline, I don't see it. It only gets shown after a reload.

(This happens with the subrepository support thingie.)

[Christopher Lenz]

Need more information here. With "reload" you mean a server restart?

What's your repository structure, and what part have you told Trac to use? Can you enabled DEBUG logging and look for repository syncing messages in the logs?

[Manuzhai]

No, just a reload of the page in the browser! On the first load of the timeline, it doesn't get the latest changeset. Repository structure: /var/svn/xm is repos, project is at /hebe (with /trunk etc in there), repository_dir set to /var/svn/xm/hebe.

Don't have time to check out the logs right now, will do that later.

[Matthew Good]

This could be due to the browser cache. What browser are you using? You may want to use something like the LiveHTTPHeaders Firefox extension to see the request and response.

[Manuzhai]

I use Firefox, and I don't think it could be the browser cache: ticket changes are always there, just not the latest changeset.

[Christian Boos]

I don't see how this could possibly happen…

Please reopen if this is still occurring for either 0.9.3 or the current trunk.

[kmccabe@…]

For what it's worth, I've seen similar behavior on Trac 0.9.2 (I'm slow on upgrades =[ ) running under mod_python. I believe it's related to your webserver setup, as it did not happen under a CGI install.

(Not that I find it to be terribly annoying, just adding my $0.01)

[john@…]

I see this all the time on my repositories. I'm using mod_python, for speed. We have >20 repositories, and CGI was too slow. I believe the crux of the problem is in svn_fs.py:get_youngest_rev(). It checks to see if it's already retreived the youngest revision, and if so, just returns what it retreived last. Unfortunately, mod_python based trac installations, are going to have the those objects hang around for quite a while, and the repository could have seen more commits. When a new web request is made, it's just going to use the cached youngest rev, and move on. Unfortunately, that means we don't get to see the latest update. Personally, I'd be happy with a post-commit hook solution to the problem that would update database tables. That way, Trac would clear the cached youngest version, sync itself up, and show the correct data.

This was still occuring in 10.1. I haven't upgraded to 10.2 yet, but I'm confident the problem still exists.

[Christian Boos]

Replying to john@szakmeister.net:

… This was still occuring in 10.1. I haven't upgraded to 10.2 yet, but I'm confident the problem still exists.

Well, upgrading to 0.10.2 would have given you the #4132 issue. Please try to upgrade to 0.10.3 which fixes both the above issue and this issue by making sure a sync() as attempter at the beginning of every request (there's a rc1 package available in TracDownload, and the upgrade is painless, only code changes, no upgrade or resync needed).

[anonymous]

I've been using 0.10.3 for over a week and can confirm the issue is gone. Thanks cboos!

[Christian Boos]

Fine! The problem described in comment:7 corresponds to #4132, and probably the original report was about that problem as well, therefore I'm closing the ticket as duplicate.