Trac 0.10.4 requires resync on solaris after every commit

[d1capelis@…]

I poked folks in the #trac channel about this one and they told me to file it. Took me a bit because I was trying to verify again that it isn't my own fault. :) The short summary isn't entirely accurate…. as sometimes with *small* repositories we don't get the error thrown, but large repos still require a resync every time. I just get the dreaded No such revision message (specifying the revision that was just committed) and it doesn't go away until I resync. I've had to install SVN hooks to resync after post-commit to make trac workable for us for now. (Love the software, just this bug tends to really interfere in workflow.) We're running trac on solaris and so it's not as well integrated as it is on linux. Frankly, even after me checking it, the bug might be an installation issue still as we had to do some pretty odd things to get it all installed.

Some details of what it's running:

python 2.3
solaris 9
trac 0.10.4
subversion 1.4.3 + bindings
openidplugin from trac-hacks

Slight code modification that seemed to be necessary with the openid plugin. (found this code change recommended in another bug on a similar issue a few version back) However, I'm pretty sure this isn't the cause of the bug: (Old code commented, my code the line above)

From trac-0.10.4/trac/db/sqlite_backend.py:

        if have_pysqlite == 2:
            self._active_cursors = weakref.WeakKeyDictionary()
            timeout = int(params.get('timeout', 10.0))
            cnx = sqlite.connect(path, detect_types=sqlite.PARSE_DECLTYPES,
                                 check_same_thread=False,
#                                 check_same_thread=sqlite_version < 30301,
                                 timeout=timeout)

Yeah, I know it's a hack, but apparently it was needed…

Anyways, back to the bug. I also get the no such revision found error whenever I view a changeset above a certain size (not sure whether it's number of files or amount of data yet) specifying that it can't find that revision. I don't get this on revisions with only a few changed lines or only a few files. But on commits with lots of things added, it seems to always throw an error, but unlike the symptom described above where after every commit, the entire trac just shows an error, this only happens when you click on a large commit and doesn't go away after a resync.

Thanks folks, keep up the good work. :)

[ThurnerRupert]

we run it for more than 2 yrs now on solaris 8 and 10 and i never saw this. could you give the ​http://blastwave.org version a try?

we noticed trac throwing an exception while trying to display a 250 files all together bigger than 1GB changeset.

[d1capelis@…]

We're using the entire blastwave toolset except for the trac modules themselves which we've compiled against the python2.3 blastwave has. Then we simply installed the 0.10.4 version over the blastwave one. (Which didn't work for us, it couldn't find the subversion bindings.)

[Christian Boos]

Make sure you're using a thread-safe SQLite. Best is to rebuild it yourself and then rebuild the latest PySqlite (check that page for download and build instructions).

[ThurnerRupert]

we are using default blastwave including sqlite. to my knowledge blastwave compiles the software for sol8, which then runs on 8, 9, 10.

[ThurnerRupert]

marked #5967 as duplicated, this time on ubuntu?

[Tim Hatch]

Formatting fix