Edgewall Software
Modify

Opened 17 years ago

Closed 16 years ago

Last modified 9 years ago

#5440 closed defect (worksforme)

0.10.4 stopped updating revision

Reported by: wichert@… Owned by: Christian Boos
Priority: high Milestone:
Component: version control Version: 0.10.4
Severity: major Keywords: weird, needinfo, postgresql
Cc: wichert@… Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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)

Attachments (0)

Change History (10)

comment:1 by wichert@…, 17 years ago

Cc: wichert@… added

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

comment:2 by Christian Boos, 17 years ago

Milestone: 0.10.5

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 :-/

comment:3 by wichert@…, 17 years ago

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.

in reply to:  3 comment:4 by Christian Boos, 17 years ago

Component: generalversion control
Owner: changed from Jonas Borgström to Christian Boos
Severity: normalmajor

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?

comment:5 by wichert@…, 17 years ago

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).

in reply to:  5 ; comment:6 by Christian Boos, 17 years ago

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?

in reply to:  6 comment:7 by Christian Boos, 17 years ago

Keywords: postgres weird added

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]").

comment:8 by Christian Boos, 16 years ago

Keywords: needinfo added
Milestone: 0.10.50.11.1

Did this happen again? Did you upgrade to psycopg2?

comment:9 by Christian Boos, 16 years ago

Milestone: 0.11.1
Resolution: worksforme
Status: newclosed

Seems to have happened again (see #6143).

Please reopen if the problem still happen with psycopg2.

comment:10 by Ryan J Ollos, 9 years ago

Keywords: postgresql added; postgres removed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Christian Boos 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.