0.10.4 stopped updating revision

[wichert@…]

I have a repository with these last two changesets:

[snowflake;..ndles/dev/CMFPlone]-20> svn log -r 43289:HEAD https://svn.plone.org/svn/collective
------------------------------------------------------------------------
r43289 | optilude | 2007-06-06 23:06:33 +0200 (Wed, 06 Jun 2007) | 2 lines

We need these dependencies

------------------------------------------------------------------------
r43290 | optilude | 2007-06-06 23:08:18 +0200 (Wed, 06 Jun 2007) | 9 lines

Refactor the plone3_theme template:

 - Viewlets live in browser/ as per Zope 3 conventions
 - Skin layer names contain namespace package to avoid clashes
 - Interface is in .browser.interfaces.IThemeSpecific (less awkward name)
 - It's always a zope 2 product (else GS and skin layers wouldn't work)
 - It's always an egg (since it uses the nested package naming)


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

looking at the trac interface trac knows that changeset 43290 exists, but it shows no information for it. Looking at the (postgres) revision table reveals that there is no data for 43290 present:

trac.collective=# select * from revision where rev='43289';
  rev  |    time    |  author  |          message           
-------+------------+----------+----------------------------
 43289 | 1181163993 | optilude | We need these dependencies

(1 row)

trac.collective=# select * from revision where rev='43290';
 rev | time | author | message 
-----+------+--------+---------
(0 rows)

enabling debug logs only shows this when trying to visit /changeset/43290:

2007-06-06 21:19:39,170 Trac[__init__] DEBUG: groups: @InfrastructureTeam,@Committers,@ArchetypesCommitters,@FrameworkTeam,@ReleaseTeam,@PloneNetReviewers,@CollectiveCommitters
2007-06-06 21:19:39,195 Trac[__init__] WARNING: 500 Internal Error (No changeset 43290 in the repository)

[wichert@…]

After taking down apache to prevent updates to the repository and running a trac-admin resync everything is working again.

[Christian Boos]

Looks like another avatar of the #4043 problem, this time a discrepancy between the system table and the revision one.

A full resync shouldn't be necessary in this situation (and that must be have been quite time consuming in your case). If this happens again, simply fix the cached youngest rev info, e.g.:

update system set value='43289' where name='youngest_rev';

I'm only half surprised the sync still doesn't work :-/

[wichert@…]

I just hit this one again. I needed to make two changes in the SQL database to get things working again:

trac.collective=# update system set value='48719' where name='youngest_rev';
UPDATE 1
trac.collective=# delete from node_change where rev='48720';
DELETE 1

without the second trac gave a id conflict error when I tried to add changeset 48720 to the node_change table while there was already an entry for it.

[Christian Boos]

Replying to wichert@wiggy.net:

… without the second trac gave a id conflict error when I tried to add changeset 48720 to the node_change table while there was already an entry for it.

But what was the value for youngest_rev before you did the first change? If that was 48720, things should have worked…

I assume you're using PostgreSQL, right? Which binding?

[wichert@…]

Before I changed the system table it looked like this:

trac.collective=# select * from system;
       name       |                                   value                                    
------------------+----------------------------------------------------------------------------
 database_version | 20
 repository_dir   | svn:db7f04ef-aaf3-0310-a811-c281ed44c4ad:/srv/svn.plone.org/svn/collective
 youngest_rev     | 48720
(3 rows)

The database driver used seems to be pyscopg 1.1.21 (debian package revision 1.1.21-14 to be precise).

[Christian Boos]

Replying to wichert@wiggy.net:

youngest_rev | 48720

Well, then it's not exactly the same thing as you initially reported. Youngest rev was known to be 48720 and there were indeed rows corresponding to the 48720 changeset in the node_change table. So what was the error, precisely? Something wrong with the revision table?

The database driver used seems to be pyscopg 1.1.21 (debian package revision 1.1.21-14 to be precise).

Maybe it's worth trying to upgrade to psycopg:PsycopgTwo?

[Christian Boos]

Follow-up to the above:

Replying to wichert@wiggy.net:

youngest_rev | 48720

… Youngest rev was known to be 48720 and there were indeed rows corresponding to the 48720 changeset in the node_change table.

… and there were probably no entries in the revision table, so yes it could be exactly the same thing as the initial report.

Looking at source:tags/trac-0.10.4/trac/versioncontrol/cache.py#L153​, I really don't understand how it's possible to end up with correct content in node_change and system without having something written in revision as well, for a given cset.

If you can show us the log file corresponding to the period were the problem occurred, maybe that this could shed some light on the issue (look for the first occurrence of "Trying to sync revision [48720]").

[Christian Boos]

Did this happen again? Did you upgrade to psycopg2?

[Christian Boos]

Seems to have happened again (see #6143).

Please reopen if the problem still happen with psycopg2.