Trac claims "The repository directory has changed" but it did not change

[Robert Jacobson]

I inherited a Trac server so I don't have a lot of info about what has done before I got here...

When a user visits the trac web page, there is a banner that says

closeWarning: Can't synchronize with repository "(default)" (The repository directory has changed, you should resynchronize the repository with: trac-admin $ENV repository resync '(default)'). Look in the Trac log for more information.

I ran a repository resync on "*", which appeared to run to completion.  The trac.log showed a lot of "Caching node change" messages, up to the current svn repository change number.  I then restarted the web server .

However, trac is still complaining that it cannot synchronize.  The repository directory didn't change in the few minutes it took to resync. (no revisions were made).

I can't figure out why it's complaining?

[Robert Jacobson]

I did find that there was a bad repo definition in the database; I did a "repository list" and it showed a repo that didn't exist, so I deleted it.

# trac-admin /path/to/trac repository list

Name       Type  Alias  Directory

---------------------------------

(default)               /repo/svn

# trac-admin /path/to/trac repository sync "*"

Resyncing repository history for (default)...

15846 revisions cached.

Done.

But when I try to browse changset 15845, it says "No such changset"

 

[Ryan Ollos]

On Thu, May 2, 2019 at 5:57 AM Robert Jacobson <ter...@gmail.com> wrote:

I did find that there was a bad repo definition in the database; I did a "repository list" and it showed a repo that didn't exist, so I deleted it.

# trac-admin /path/to/trac repository list

Name       Type  Alias  Directory

---------------------------------

(default)               /repo/svn

Is that the output listing the bad repository, or the output after you removed the bad repository definition?

I'm confused because the error message was about synchronizing "(default)", and then below it shows you have successfully synced "(default)".

Make sure you don't have conflicting repository definitions in the database and the [repositories] section of trac.ini.

https://trac.edgewall.org/wiki/TracRepositoryAdmin#Repositories

Which Trac version?

 

# trac-admin /path/to/trac repository sync "*"

Resyncing repository history for (default)...

15846 revisions cached.

Done.

But when I try to browse changset 15845, it says "No such changset"

Is it just that one changeset that's missing, or do you get the same message with any random choice of changeset revisions?

Debug level logging might provide more info, both for the caching action and the repository browsing action:

https://trac.edgewall.org/wiki/TracTroubleshooting#ChecktheLogs

- Ryan 

[Robert Jacobson]

Thanks for responding.  I fixed my problem, though I do not understand how what I did fixed it.  

Apparently whoever migrated the Trac instance did not ever complete a "deploy" command, or they did it incorrectly.  They did everything else (upgrade, wiki upgrade, repository sync), but not a deploy.

After I ran deploy, all the missing changesets appeared in the repo browser in Trac.  If you have an idea why that might be, I'd appreciate the feedback.  Otherwise I'm just happy that it's working.

FWIW, this is Trac 1.2.3 (I think, that's from memory).  Since you took the time to attempt to answer my questions, I'll also answer yours :) 

Make sure you don't have conflicting repository definitions in the database and the [repositories] section of trac.ini.

The trac.ini definition matched the database -- at least, after I removed the incorrect one.

Is that the output listing the bad repository, or the output after you removed the bad repository definition?

Sorry, that was the output after I removed the bad definition.

Is it just that one changeset that's missing, or do you get the same message with any random choice of changeset revisions?

All changesets since the upgrade were reported as missing.   Users continued to use svn-native tools to commit changes to the repo; those did not appear in the browser -- though they did in the database.  All the "old" changesets were correctly reported in the browser.

Thanks again for your time.

[RjOllos]

On Thursday, May 2, 2019 at 9:24:07 PM UTC-4, Robert Jacobson wrote:

Thanks for responding.  I fixed my problem, though I do not understand how what I did fixed it.  

Apparently whoever migrated the Trac instance did not ever complete a "deploy" command, or they did it incorrectly.  They did everything else (upgrade, wiki upgrade, repository sync), but not a deploy.

After I ran deploy, all the missing changesets appeared in the repo browser in Trac.  If you have an idea why that might be, I'd appreciate the feedback.  Otherwise I'm just happy that it's working.

FWIW, this is Trac 1.2.3 (I think, that's from memory).  Since you took the time to attempt to answer my questions, I'll also answer yours :) 

Glad to hear its fixed. The deploy command won't have a direct impact on the repository synchronization, it just extracts the static assets to a directory and creates the wsgi script. Maybe there is an unexpected side effect of deploy in your configuration.

Could "restart web server" have been the important step?

 

Make sure you don't have conflicting repository definitions in the database and the [repositories] section of trac.ini.

The trac.ini definition matched the database -- at least, after I removed the incorrect one.

Just to be sure, repositories should be defined in either trac.ini or the database. In theory you could use both, but the entries in each should be unique. If not, one of the entries will be ignored and the results could be confusing. You shouldn't, for example, define "reposA" in trac.ini and the database. But you could define "reposA" in the database and "reposB" in trac.ini. Most users choose to use just one of the repository providers.