Changeset cache won't update if p4d rebooted during previous run

[Lewis Baker]

From ticket #645 by excentric@…

The Perforce server here was rebooted in the middle of the plugin looking through the change/revision history. When the server came back and i tried to force my Trac site to browse the source again I got an error similar to the following "column rev not unique". Wiping the node and revision tables allowed me to continue.

[anonymous]

I've found an easy way to reproduce this without the need for rebooting or turning off your perforce server. Set up an ssh perforce tunnel with "ssh -L 1666:localhost:1666 root@perforce". Start the initial perforce changelist grab and then in the middle of it logout of the tunnel. This will cause the issue I described above. Also like i said "delete from revision" and node_change allows to start the change list grab again

[Lewis Baker]

I suspect this is due to the transaction not being rolled back if the perforce.Connection.run() method raises perforce.ConnectionDropped.

A try/except block around some logic in p4trac.api.PerforceCachedRepository's storeChangesInDB() method to roll back on an exception should do the trick.

[Lewis Baker]

Change [1215] should better handle being disconnected from the Perforce server during the cache sync.

However I think there may still be issues lurking if you have changesets that have out-of-order timestamps. This can cause problems with sync() as the get_youngest_rev_in_cache() method currently returns the youngest changeset by timestamp rather than by change number, which can result in the plugin attempting to cache changes that have already been cached.

A more general fix would probably require a change to the revision table schema to make the rev field an integer rather than a string so that records can be sorted numerically by change number. I'm not sure what the implications of doing this would be for other parts of Trac, though.

[Ryan J Ollos]

Plugin is deprecated.