#6175 "Repository: code" not up-to-date and commits not displaying
Originally created by: brlcad
After migration to Allura last week, it seems that our code view (previously viewvc) has stopped updating: https://sourceforge.net/p/brlcad/code/HEAD/tree/
The latest commit listed there is 55207, yet our latest repository revision is 55269+. That stalled version corresponds to the state of our repository prior to the conversion. I've attempted to "Refresh Repository" a couple of times on the admin page without success. Is there something we're doing wrong?
Perhaps related, perhaps unrelated -- we can also not browse commits: https://sourceforge.net/p/brlcad/code/commit_browser
The initial import ran from 2013-04-22T20:05 to 2013-04-23T03:04, with no apparent errors. A "refresh" job is currently running, started 2013-04-23T00:29. Since it is still running, it prevents further updates from running until it finishes. It found 34285 commits to index at that point. It completed the "Refresh commit info" steps by 2013-04-23T02:58. "Refresh child info" steps ran from 03:04 to 03:05. Most other steps are skipped by SVN refreshes. By deduction, the user stats logic remains.
Originally by: brlcad
So the initial import took 7 hours, but now there's a "refresh" still running ... after 15 days?
Are you saying that it won't finish refreshing until we stop making a commit for at least 7 consecutive hours? I manually requested a refresh on 04-30, how does that come into play? Is it stuck on something? I'm not seeing a deductive explanation that accounts for a refresh job started on 04-23 that is still running.
I'm still looking into the current job to figure out why it's taking so long - clearly not right :) I'll post more here as I figure it out.
You can continue to make commits, don't worry about that. The manual refreshes (and those triggered by new commits) aren't doing anything right now since we don't let two refreshes run at the same time (they can step on each others' toes).
Originally by: brlcad
Thanks, that's refreshing. I don't think I could easily stop all of our devs anyways. :)
Curious that it only found 34285 commits as we are on 55200+ ... the difference isn't accounted for by branch activity either.
We killed the runaway "refresh" process, and now the repo metadata is up to date, and new commits should be handled timely too.
Root cause was some statistic processing that was performing very badly on the 34285 new commits. It's not clear why it was trying to handle 34285 commits, but we'll put some safeguards in place just in case it were to happen again.