Edgewall Software

Opened 3 years ago

Closed 3 years ago

#12778 closed defect (invalid)

No refresh of Trac with multiple instances on the same SVN repo

Reported by: even.rouault@… Owned by:
Priority: normal Milestone:
Component: version control Version: 1.2
Severity: normal Keywords: svn
Cc: strk@… Branch:
Release Notes:
API Changes:


I'm not sure the report is properly written, but I'm not an admin of the server on which we are seeing the issue. The administrator (CC'ed) advised me to report upstream as he thinks that's an issue of Trac itself rather than the deployment and configuration of the instance.

So we have a SVN repo /var/www/svn/repos/metacrs that has several subdirectories, with "geotiff" being one of them. We have a https://trac.osgeo.org/metacrs and https://trac.osgeo.org/geotiff instances.

The configuration of the later is

.dir = /var/www/svn/repos/metacrs/geotiff/
.sync_per_request = true # see https://trac.osgeo.org/osgeo/ticket/1910 - TODO: set to false again
^^^ the above section does NOT result in proper sync of revisions, while *dropping* the `/geotiff/` component in the `.dir` path does work in showing all revisions
SVNRoot being ...repos/metacrs (to complete the info)

When I commit in the geotiff subdirectory, the https://trac.osgeo.org/metacrs instance sees the commit, but the geotiff one not

It used to work with Trac 1.0 while it's failing with 1.2 (r15513)

Attachments (0)

Change History (8)

comment:1 by Jun Omae, 3 years ago

Component: generalversion control
Keywords: svn added

comment:2 by Jun Omae, 3 years ago

It seems Subversion repository with scope doesn't work.

comment:3 by Jun Omae, 3 years ago

It cannot be reproduced with mirror of https://svn.osgeo.org/metacrs/ and .sync_per_request = enabled but log page shows 47 years before repository cache is created.

I consider explicit synchronization doesn't work in https://trac.osgeo.org/geotiff. Make sure changeset added command is executed from post-commit hook. Also, could you please trac.log in the Trac environment if the synchronization is invoked.

comment:4 by strk@…, 3 years ago

Explicit synchronization is not setup for the geotiff environment, because we're using a generic SVN post-commit hook which is the one that make all commits of all subproject appear in the metacrs (parent) env. Enabling explicit sync for the subprojects would require figuring out which subproject each commit belongs to, which is something I think we should do but doesn't belong to this bug report …

The log shows NO per-page synchronization info, with level = INFO. Is INFO supposed to show that info ?

comment:5 by strk@…, 3 years ago

Even DEBUG level tells nothing about repository sync (how would it look?). I did not understand the 47 years thing you mentioned, Jun Omae

comment:6 by anonymous, 3 years ago

Wait: I think I found a trace:

[2017-04-18 12:01:16,774] geotiff:api INFO: Synchronized '(default)' repository in 0.03 seconds

comment:7 by Sandro Santilli <strk@…>, 3 years ago

Figured ! It's the presence of a comment after the true value that is not considered a true value:

.sync_per_request = true # see https://trac.osgeo.org/osgeo/ticket/1910 - TODO: set to false again

Using a semicolon works as (I'm afraid) is expected by Ini format !

comment:8 by Sandro Santilli <strk@…>, 3 years ago

Resolution: invalid
Status: newclosed

So to recap: the fact that things worked in 1.0 was due to the fact that per-page synchronization was on by default. After upgrade to 1.2 we switched (I thought) to explicit sync, but this sub-directory layout was not handled appropriately. When figured this out, re-enabling per-request sync was failing due to bogus syntax (my fault). I'm closing the issue as invalid. For reference, the downstream issue was: https://trac.osgeo.org/osgeo/ticket/1910

Modify Ticket

Change Properties
Set your email in Preferences
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.
to as closed 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.