NoSuchChangeset

[nathan.schindler@…]

After upgrading from 0.10 to 0.10.1 I'm seeing an error when I look at the timeline. After some commits (not every time) the page displays:

Repository checkins event provider (ChangesetModule) failed:
NoSuchChangeset: No changeset <rev> in the repository

<rev> would be the latest repository revision.

"trac-admin /path/to/project resync" doesn't help. My current work-around is to restart httpd. If I do that, it'll behave for 1 to 3 commits.

The system runs RHEL4 Update 2, httpd 2.0.52, python 2.3.4, subversion 1.4.2, and trac 0.10.1

---

Note: this issue was introduced in 0.10.1, and is believed to be fixed in 0.10.3dev, so if you're experiencing this issue, you should upgrade to the latest of source:branches/0.10-stable,

$ svn co http://svn.edgewall.org/repos/trac/branches/0.10-stable
$ cd 0.10-stable
$ python setup.py install

If you're still seeing a problem after that, please create a new ticket.
--cboos

[cboos]

I think that it's another effect of r3972, though it's not yet clear for me how this can happen...

Can you please copy/attach the log containing the DEBUG level info at the time you get this error?

[aron@…]

I'm getting the same error (trac-10.1) while viewing the timeline. When the timeline problems occur the browser also reports that the latest changeset doesn't exists. No changeset <rev> in the repository

System:
Apache 2.0.58, mod_python 3.1.4, Python 2.4.2, mod_ssl 2.0.58, OpenSSL 0.9.8d, PHP 5.2.0.

Will post a log as soon as the error reoccurs again (had to restart apache, which temporarily "fixes" the bug).

[aron@…]

Sorry guys, need trac so much that I can't wait any longer to downgrade to 10.0 so I won't post a log :(

[mark@…]

I'm seeing these same two problems on an intermittent basis. Timeline, Source Browser, links into a Changeset all seem to be having sit-and-spin problems. I've turned trac's logging to DEBUG, but the only trac output refers to loading egg plugins...

Links seem to work for a while, then start to hang. I'll happily post a log if somebody can help figure out how to get something worthwhile out.

trac 0.10.1 (upgraded by yum this morning) fedora core 5 subversion 1.3.2 apache 2.2.2

Cheers - Mark

[trac-ja@…]

I took a log, but rejected as Spam :(

I found SubversionRepository.yougest_rev is older than rev (parameter) in source:branches/0.10-stable/trac/versioncontrol/svn_fs.py@4254#L333

Since 0.11, Trac uses SubversionRepository and CachedRepository in versioncontrol subsystem. When we uses multi-proccess and/or multi-thread environments (ex. mod_python), database-backend updates from one process or thread's CachedRepository.sync(), And others will reload new revisons in a few times. But SubversionRepository's cache (class fields, ex. self.yougest) don't have a trigger to update to new revision that commited after repositoy-connection opened.

[anonymous]

Debug output durring error

[nathan.schindler@…]

I've attached my debug output. What I did during the log capture was: 1) Navigate to a new commit, r213 in the timeline: timeline loaded fine, but got the following error when trying to view the changeset: "No changeset 213 in the repository" 2) Browsed to r213 of stdafx.h in the source browser: opened fine 3) Clicked on the Wiki: just for fun, worked fine 4) Went back to the timeline: got error "NoSuchChangeSet?: No changeset 213 in the repository"

If I click around, such as navigating to the Wiki and back to the Timeline, sometimes it'll let me see the changeset, sometimes it won't.

[nathan.schindler@…]

Still happens in 0.10.2

[dzuelke@…]

same problem here in 0.10.2

[csapuntz@…]

I'm seeing these errors often but not always:

Repository checkins event provider (ChangesetModule?) failed:

NoSuchChangeset?: No changeset xxxx in the repository

---

Plugins:

• Trac 0.10.2
• Bitten 0.5.3
• TracWebAdmin 0.1.2dev-r3772
• Codetags 0.1 -- disabled

We're using sqlite 3.3.3 on Centos 4.

One traceback seemed to indicate the problem was in normalize_rev called from sync in the cache module.

Rolling back to Trac 0.10.0 fixes the problem.

[csapuntz@…]

I'm also seeing log messages like this:

2006-11-14 14:17:33,144 Trac[cache] INFO: Syncing with repository (7297 to 7294)

[trac-ja@…]

I wrote a patch for source:branches/0.10-stable@4275.

Review it, please.

Index: trac/versioncontrol/api.py
===================================================================
--- trac/versioncontrol/api.py  (revision 4274)
+++ trac/versioncontrol/api.py  (working copy)
@@ -169,6 +169,10 @@
         raise NotImplementedError
     youngest_rev = property(lambda x: x.get_youngest_rev())

+    def get_youngest_rev_in_repos(self):
+        """Return the youngest revision in the real repository."""
+        raise NotImplementedError
+
     def previous_rev(self, rev):
         """Return the revision immediately preceding the specified revision."""
         raise NotImplementedError
Index: trac/versioncontrol/svn_fs.py
===================================================================
--- trac/versioncontrol/svn_fs.py       (revision 4274)
+++ trac/versioncontrol/svn_fs.py       (working copy)
@@ -331,7 +331,10 @@
         if rev is None:
             rev = self.youngest_rev
         elif rev > self.youngest_rev:
-            raise NoSuchChangeset(rev)
+            self.youngest = None
+            self.get_youngest_rev()
+            if rev > self.youngest_rev:
+                raise NoSuchChangeset(rev)
         return rev

     def close(self):
@@ -380,12 +383,16 @@

     def get_youngest_rev(self):
         if not self.youngest:
-            self.youngest = fs.youngest_rev(self.fs_ptr, self.pool())
-            if self.scope != '/':
-                for path, rev in self._history('', 0, self.youngest, limit=1):
-                    self.youngest = rev
+            self.get_youngest_rev_in_repos()
         return self.youngest

+    def get_youngest_rev_in_repos(self):
+        self.youngest = fs.youngest_rev(self.fs_ptr, self.pool())
+        if self.scope != '/':
+            for path, rev in self._history('', 0, self.youngest, limit=1):
+                self.youngest = rev
+        return self.youngest
+
     def previous_rev(self, rev, path=''):
         rev = self.normalize_rev(rev)
         return self._previous_rev(rev, path)
Index: trac/versioncontrol/cache.py
===================================================================
--- trac/versioncontrol/cache.py        (revision 4274)
+++ trac/versioncontrol/cache.py        (working copy)
@@ -40,13 +40,18 @@
         if not self.synced:
             self.sync()
             self.synced = 1
+        try:
+            return CachedChangeset(self.repos.normalize_rev(rev), self.db,
+                                   self.authz)
+        except NoSuchChangeset:
+            self.sync()
+            self.synced = 1
         return CachedChangeset(self.repos.normalize_rev(rev), self.db,
                                self.authz)

     def get_changesets(self, start, stop):
-        if not self.synced:
-            self.sync()
-            self.synced = 1
+        self.sync()
+        self.synced = 1
         cursor = self.db.cursor()
         cursor.execute("SELECT rev FROM revision "
                        "WHERE time >= %s AND time < %s "
@@ -72,8 +77,9 @@
                               "a 'trac-admin resync' operation is needed.")

         youngest_stored = self.repos.get_youngest_rev_in_cache(self.db)
+        youngest_repos = self.repos.get_youngest_rev_in_repos()

-        if youngest_stored != str(self.repos.youngest_rev):
+        if youngest_stored < str(youngest_repos):
             authz = self.repos.authz
             self.repos.authz = Authorizer() # remove permission checking

[cboos]

The patch looks good (except for the last str() comparison, should use repos.rev_older_than instead, as "100" < "99"), but I'd rather go in a different direction.

I don't think it's a good thing to trigger a sync() from multiple places in the program. I'd rather have one request give a coherent view on the repository, a "snapshot" of it. It's anyway the direction I'd like to take in future incarnations of the versioncontrol layer, where it should be possible to have responsiveness even for backends that are slow to interact with (all of them actually ;) ), as most of the operations will happen on the cache.

I prefer to call sync() at the beginning of the processing of a request, see #4120 .

Then, related to comment:5:

But SubversionRepository's cache (class fields, ex. self.yougest) don't have a trigger to update to new revision that commited after repositoy-connection opened.

youngest is not a class field, it's an instance field, and there's one SubversionRepository instance per request/thread.

But other than that, your analysis of the cause of the problem is correct (it explains the "weird" output reported in comment:12), so I think the "right" approach would be that the CachedRepository.youngest_rev calls self.repos.get_youngest_rev_in_cache instead of self.repos.youngest.

[anonymous]

In mod_python enviroment, CR and SR instances are cached per process. These instances are kept while httpd running. So, sync() and refresh SR.youngest run just once when httpd start.

A instance can know yungest in repos and update revision table when call sync(). But other instances cannot know about it. I think, in this case, All instances must call sync() and refresh SR.youngest per request.

Are there performance issues? Think later :)

patch for source:branches/0.10-stable@4286.

Index: trac/versioncontrol/api.py
===================================================================
--- trac/versioncontrol/api.py  (revision 4286)
+++ trac/versioncontrol/api.py  (working copy)
@@ -81,6 +81,7 @@
             tid = threading._get_ident()
             if tid in self._cache:
                 repos = self._cache[tid]
+                repos.refresh()
             else:
                 rtype, rdir = self.repository_type, self.repository_dir
                 repos = self._connector.get_repository(rtype, rdir, authname)
@@ -120,6 +121,10 @@
         """Close the connection to the repository."""
         raise NotImplementedError

+    def refresh(self):
+        """Refresh caches in instance."""
+        raise NotImplementedError
+
     def get_changeset(self, rev):
         """Retrieve a Changeset corresponding to the  given revision `rev`."""
         raise NotImplementedError
Index: trac/versioncontrol/svn_fs.py
===================================================================
--- trac/versioncontrol/svn_fs.py       (revision 4286)
+++ trac/versioncontrol/svn_fs.py       (working copy)
@@ -340,6 +340,10 @@
         self.fs_ptr = None
         self.pool = None

+    def refresh(self):
+        self.youngest = None
+        self.oldest = None
+
     def get_changeset(self, rev):
         return SubversionChangeset(int(rev), self.authz, self.scope,
                                    self.fs_ptr, self.pool)
Index: trac/versioncontrol/cache.py
===================================================================
--- trac/versioncontrol/cache.py        (revision 4286)
+++ trac/versioncontrol/cache.py        (working copy)
@@ -36,6 +36,10 @@
     def close(self):
         self.repos.close()

+    def refresh(self):
+        self.synced = 0
+        self.repos.refresh()
+
     def get_changeset(self, rev):
         if not self.synced:
             self.sync()

[cboos]

I'd be interested in getting some feedback for the following patch: attachment:sync_only_once-r4292.diff

[cboos]

Only sync the repository once per request.

[dkg-debian.org@…]

Seeing this in 0.10.2 also. I'm working on testing the patch.

[Nate Schindler <nathan.schindler@…>]

Regarding the patch from comment 18:

This patch fails against 0.10.1 or 0.10.2, so I had to remove/modify some lines manually:

(Stripping trailing CRs from patch.)
patching file trac/versioncontrol/api.py
(Stripping trailing CRs from patch.)
patching file trac/versioncontrol/cache.py
Hunk #1 FAILED at 34.
Hunk #2 succeeded at 113 (offset -3 lines).
1 out of 2 hunks FAILED -- saving rejects to file trac/versionconrol/cache.py.rej

cache.py.rej (when run against 0.10.1):

***************
*** 34,55 ****
          Repository.__init__(self, repos.name, authz, log)
          self.db = db
          self.repos = repos
-         self.synced = 0

      def close(self):
          self.repos.close()

      def get_changeset(self, rev):
-         if not self.synced:
-             self.sync()
-             self.synced = 1
          return CachedChangeset(self.repos, self.repos.normalize_rev(rev),
                                 self.db, self.authz)

      def get_changesets(self, start, stop):
-         if not self.synced:
-             self.sync()
-             self.synced = 1
          cursor = self.db.cursor()
          cursor.execute("SELECT rev FROM revision "
                         "WHERE time >= %s AND time < %s "
--- 34,48 ----
          Repository.__init__(self, repos.name, authz, log)
          self.db = db
          self.repos = repos

      def close(self):
          self.repos.close()

      def get_changeset(self, rev):
          return CachedChangeset(self.repos, self.repos.normalize_rev(rev),
                                 self.db, self.authz)

      def get_changesets(self, start, stop):
          cursor = self.db.cursor()
          cursor.execute("SELECT rev FROM revision "
                         "WHERE time >= %s AND time < %s "

Manually finished patching and restarted httpd. After my 3rd commit, I got the following:

2006-11-15 09:14:06,317 Trac[cache] INFO: Syncing with repository (217 to 215)
2006-11-15 09:14:06,333 Trac[main] ERROR: No changeset 217 in the repository
Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 387, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 176, in dispatch
    chosen_handler = self._pre_process_request(req, chosen_handler)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 264, in _pre_process_request
    chosen_handler = f.pre_process_request(req, chosen_handler)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/api.py", line 75, in pre_process_request
    repos.sync()
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/cache.py", line 78, in sync
    current_rev = self.repos.next_rev(youngest_stored)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 394, in next_rev
    rev = self.normalize_rev(rev)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 334, in normalize_rev
    raise NoSuchChangeset(rev)
NoSuchChangeset: No changeset 217 in the repository

If I click the Timeline link in the top navbar 3 or 4 more times, the expected list will display again, but I can't access any changesets until I restart httpd.

[dkg-debian.org@…]

I got the same results as Nate above. Manually forced in the patch, restarted apache2 (prefork model), and my timeline cleared up. Did two test commits, testing the timeline after each one. After the second, i got an "oops, trac detected internal error", with the following backtrace in the browser:

Traceback (most recent call last):
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 387, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 176, in dispatch
    chosen_handler = self._pre_process_request(req, chosen_handler)
  File "/usr/lib/python2.3/site-packages/trac/web/main.py", line 264, in _pre_process_request
    chosen_handler = f.pre_process_request(req, chosen_handler)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/api.py", line 75, in pre_process_request
    repos.sync()
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/cache.py", line 78, in sync
    current_rev = self.repos.next_rev(youngest_stored)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 394, in next_rev
    rev = self.normalize_rev(rev)
  File "/usr/lib/python2.3/site-packages/trac/versioncontrol/svn_fs.py", line 334, in normalize_rev
    raise NoSuchChangeset(rev)
NoSuchChangeset: No changeset 337 in the repository

[dkg-debian.org@…]

to be clear, i am doing this testing (and applying the patch) against trac 0.10.2.

[cboos]

Ok, sorry, next time I'll post a patch against 0.10.2.

Thanks for the backtraces.

[mgood]

Replying to cboos:

I'd be interested in getting some feedback for the following patch: attachment:sync_only_once-r4292.diff

Yeah, that seems alright. This should also eliminate the need for the try/except added to workaround #4120.

Would it make sense to call self.sync() at the end of CachedRepository.__init__? Or the SubversionConnector could call it when creating a new instance here: source:trunk/trac/versioncontrol/svn_fs.py@r4200#L262

That would ensure if people were using the APIs outside of a web request they would still be synced.

[cboos]

Replying to mgood:

... Would it make sense to call self.sync() at the end of CachedRepository.__init__? Or the SubversionConnector could call it when creating a new instance here: source:trunk/trac/versioncontrol/svn_fs.py@r4200#L262

Yes, either way, preferably the first one, as after all it doesn't make sense to use the CachedRepository if it hasn't be synced before.

Updated patch forthcoming, also hopefully fixing the previously reported exceptions...

[cboos]

Oh, but of course, as shutdown(tid) is never called in the apache/prefork setup described here, and the CachedRepository instance is reused over and over again, an explicit sync() is nevertheless needed in the IRequestFilter.

[cboos]

Only sync the repository once per request and clear the cached values at the instance level. Patch on 0.10-stable.

[cboos]

Voila. Hope I have better luck with this one: attachment:sync_only_once_0.10-stable-r4280.diff

[Nate Schindler <nathan.schindler@…>]

Replying to cboos:

Voila. Hope I have better luck with this one: attachment:sync_only_once_0.10-stable-r4280.diff

Patch succeeds (0.10.2), 10 commits, 0 errors. Thanks, cboos. This one looks like a winner.

[dkg-debian.org@…]

Replying to cboos:

Voila. Hope I have better luck with this one: attachment:sync_only_once_0.10-stable-r4280.diff

Works for me as well against 0.10.2. i've tested 4 commits with not further problems. Thanks for the patch.

[trac-ja@…]

Replying to cboos:

Voila. Hope I have better luck with this one: attachment:sync_only_once_0.10-stable-r4280.diff

It works with source:branches/0.10-stable@4298. Thank you. I tested such suituation that all preforked precesses loaded CB and SB instances on apache/prefork + mod_python.

However I think, it is good that remove self.log.debug() on source:branches/0.10-stable/trac/versioncontrol/cache.py@4298#L59. It logged each request now.

How long do you release trac-0.10.3? I want it A.S.A.P. :)

[mgood]

Replying to cboos:

Oh, but of course, as shutdown(tid) is never called in the apache/prefork setup described here, and the CachedRepository instance is reused over and over again, an explicit sync() is nevertheless needed in the IRequestFilter.

Why not? We already had a discussion about this for r3980 and I thought this worked. The shutdown(tid) is skipped only when wsgi.run_once is True, which AFAIK is only true for CGI, where the cache will obviously not be carried over between requests.

[cboos]

Replying to mgood:

Replying to cboos:

Oh, but of course, as shutdown(tid) is never called in the apache/prefork setup described here,...

Why not? We already had a discussion about this for r3980 and I thought this worked. The shutdown(tid) is skipped only when wsgi.run_once is True...

You're right, it's simply that we haven't ported that yet to 0.10-stable. I only looked there and forgot that we changed this in trunk. This is now in stable as well (r4300).

Thanks you all for the feedback, I've now committed the patch, along with the suggested changes (r4303).

Whether this is worth a 0.10.3 release or not remains to be seen... In the meantime, all the changes from 0.10.2 can be found here: diff:branches/0.10-stable@4266//branches/0.10-stable@4303

[dkg-debian.org@…]

I think this warrants 0.10.3. The latest stable release of trac should not have these problems.

[dkg-debian.org@…]

here's a cleaner way to show all the stable changes since 0.10.2: diff:tags/trac-0.10.2//branches/0.10-stable

[dzuelke@…]

Replying to dkg-debian.org@fifthhorseman.net:

I think this warrants 0.10.3. The latest stable release of trac should not have these problems.

I second that

[sambloomquist]

Replying to dkg-debian.org@fifthhorseman.net:

I think this warrants 0.10.3. The latest stable release of trac should not have these problems.

I'm still seeing this problem even after applying the above 0.10.3 diff to my 0.10.2 build. The troublesome code seems to be in the cache.py:

class CachedChangeset(Changeset):

    def __init__(self, rev, db, authz):
        self.db = db
        self.authz = authz
        cursor = self.db.cursor()
        cursor.execute("SELECT time,author,message FROM revision "
                       "WHERE rev=%s", (rev,))
        row = cursor.fetchone()
        if row:
            date, author, message = row
            Changeset.__init__(self, rev, message, author, int(date))
        else:
            raise NoSuchChangeset(rev)

The NoSuchChangeset?(rev) always gets raised even though there is most definitely a record in my revision table for rev. When I try executing the SQL directly using the SQLite Database Browser, the record always comes back.

[sambloomquist]

As a quick workaround until the real problem gets fixed, I was able to turn off the subversion repository caching by commenting out line 261 in svn_fs.py:

#crepos = CachedRepository(self.env.get_db_cnx(), repos, None, self.log)

and replacing it with this line:

crepos = repos

[cboos]

Replying to sambloomquist:

I'm still seeing this problem even after applying the above 0.10.3 diff to my 0.10.2 build. The troublesome code seems to be in the cache.py: ... The NoSuchChangeset(rev) always gets raised even though there is most definitely a record in my revision table for rev.

Can you add some print or log statements to the above code, in order to see what happens? Also, print rev and self.youngest_rev from there.

Besides this, I just realized that the current code is not multithread-safe, i.e. if we have two concurrent sync() attempts, one will succeed and the other will fail (pk constraint violation). So I think we should find a how to update the revision and node_change tables "atomically"... not trivial I guess, but that would also help for the #3831/#4043 issues.

[paul.drummond@…]

Hi guys, I am also having the NoSuchChangeSet problem - I was just wondering, as this is a general problem with 0.10 (am I right?) shouldn't this ticket have a severity of blocker?

[Lutz Frommberger <trac@…>]

It is not a blocker... at least for me, the problem is temporary. You just have to click on timeline three or four times, then it works. Anyway, I am also urgently waiting for 0.10.3, having the choice between security holes and angry users...

[paul.drummond@…]

Replying to Lutz Frommberger <trac@aussagekraft.de>:

It is not a blocker... at least for me, the problem is temporary. You just have to click on timeline three or four times, then it works. Anyway, I am also urgently waiting for 0.10.3, having the choice between security holes and angry users...

Whenever I do a commit, Trac doesn't recognise the change - I can refresh the "Browse Source" several times, then suddenly the change appears, but the next time I refresh it goes away again! This is a unstable behaviour and therefore constitutes blocker status IMO.

[sambloomquist]

Replying to anonymous:

Can you add some print or log statements to the above code, in order to see what happens? Also, print rev and self.youngest_rev from there.

The CachedChangeset object doesn't have a self.log or self.env.log, so I haven't figured out how to log debug messages from there yet.

I can tell that 'rev' equals 1 at this point, though, because it's passed into the NoSuchChangeset class init and subsequently printed to the screen and log. The CachedChangeset object also does not have a self.youngest_rev. Perhaps you're thinking of the SubversionRepository.normalize_rev() method -- which is the other place this error can be raised, but which is not the code that is causing my error.

Here is the log trace when I get the error:

2006-11-17 12:28:00,811 Trac[svn_fs] DEBUG: Opening subversion file-system at D:/Claims/trac/SVN/covver with scope /
2006-11-17 12:28:00,811 Trac[cache] DEBUG: Checking whether sync with repository is needed
2006-11-17 12:28:00,872 Trac[api] DEBUG: Updating wiki page index
2006-11-17 12:28:00,951 Trac[svn_fs] DEBUG: Closing subversion file-system at D:/Claims/trac/SVN/covver
2006-11-17 12:28:01,122 Trac[svn_fs] DEBUG: Opening subversion file-system at D:/Claims/trac/SVN/covver with scope /
2006-11-17 12:28:01,122 Trac[cache] DEBUG: Checking whether sync with repository is needed
2006-11-17 12:28:01,201 Trac[svn_fs] DEBUG: Closing subversion file-system at D:/Claims/trac/SVN/covver
2006-11-17 12:28:02,904 Trac[svn_fs] DEBUG: Opening subversion file-system at D:/Claims/trac/SVN/covver with scope /
2006-11-17 12:28:02,904 Trac[cache] DEBUG: Checking whether sync with repository is needed
2006-11-17 12:28:03,061 Trac[svn_fs] DEBUG: Closing subversion file-system at D:/Claims/trac/SVN/covver
2006-11-17 12:28:03,201 Trac[svn_fs] DEBUG: Opening subversion file-system at D:/Claims/trac/SVN/covver with scope /
2006-11-17 12:28:03,201 Trac[cache] DEBUG: Checking whether sync with repository is needed
2006-11-17 12:28:03,326 Trac[svn_fs] DEBUG: Closing subversion file-system at D:/Claims/trac/SVN/covver
2006-11-17 12:28:04,874 Trac[svn_fs] DEBUG: Opening subversion file-system at D:/Claims/trac/SVN/covver with scope /
2006-11-17 12:28:04,874 Trac[cache] DEBUG: Checking whether sync with repository is needed
2006-11-17 12:28:04,983 Trac[svn_fs] DEBUG: Closing subversion file-system at D:/Claims/trac/SVN/covver
2006-11-17 12:28:04,983 Trac[main] WARNING: 500 Internal Error (Repository checkins  event provider (<tt>ChangesetModule</tt>) failed:<br /><br />NoSuchChangeset: No changeset 1 in the repository<p>You may want to see the other kind of events from the <a href="/projects/covver.db/timeline?milestone=on&amp;ticket=on&amp;wiki=on">Timeline</a></p>)

For background, I started seeing this error after setting up a new repository for an existing instance of Trac. My steps were as follows:

1. Create new repository.
2. Import a bunch of code into the repository under revision 1.
3. Create new trac project instance with trac-admin initenv
4. Copy an existing trac sqlite database into the new instance 'db' folder over the newly-created database.
5. Drop the 'revision' and 'node_change' data from the sqlite database.
6. Perform a trac-admin 'resync' operation which completes successfully. At this point the 'revision' and 'node_change' tables match the new subversion repository perfectly.
7. Click the Timeline tab in a browser -- get the NoSuchChangeset error.

[cboos]

Replying to paul.drummond@serco.com:

Hi guys, I am also having the NoSuchChangeSet problem - I was just wondering, as this is a general problem with 0.10

No, it's not. It's a problem with 0.10.2, with already a proposed fix in 0.10.3dev, i.e. what you can currently find in source:branches/0.10-stable.

I reopened the issue because of comment:36, where sam explicitly stated that he was using the 0.10.3dev fix. Please don't add confusion here, things are already complex enough ;) If you have 0.10.2 and are experiencing the problem (which is to be expected if you're using apache/prefork) then upgrade to latest of 0.10-stable. Then, if you still have an issue, come back here and explain what the problem is.

[cboos]

Replying to Lutz Frommberger <trac@aussagekraft.de>:

It is not a blocker... at least for me, the problem is temporary. You just have to click on timeline three or four times, then it works.

So now I'm getting confused... is this with 0.10.2 or 0.10.3dev?

[Lutz Frommberger <trac@…>]

Replying to cboos:

Replying to Lutz Frommberger <trac@aussagekraft.de>:

It is not a blocker... at least for me, the problem is temporary. You just have to click on timeline three or four times, then it works.

So now I'm getting confused... is this with 0.10.2 or 0.10.3dev?

0.10.2

[cboos]

As this is a frequent issue, I added some indications about the fix directly in the description, which will be useful while waiting for 0.10.3.

[cboos]

Replying to sambloomquist:

... I started seeing this error after setting up a new repository for an existing instance of Trac. My steps were as follows: ...

I begin to wonder if this has really something to do with the original error... If nobody else is seeing this, I'd suggest creating a new ticket dedicated to the above issue (if the problem is still there).

[anonymous]

Replying to cboos:

Replying to sambloomquist:

... I started seeing this error after setting up a new repository for an existing instance of Trac. My steps were as follows: ...

I begin to wonder if this has really something to do with the original error... If nobody else is seeing this, I'd suggest creating a new ticket dedicated to the above issue (if the problem is still there).

Works for me. I submitted ticket #4230.

[kaouete@…]

Hi,

i tried to apply the 0.10-stable patch that were linked to this bug (that is : r4300 and r4303) and i dont get anymore errors in trac and in the logs, but until i restart apache, new commits dont appear in the timeline nor in the source.

I want to add that i am using several projects using subdirectory of an uniq repository as their respective repository.

[cboos]

Try to upgrade to the latest revision of the stable branch instead of applying only a patch, as there were follow-up changes.

Please report back if everything works for you then.

[kaouete@…]

you were right, it works well now with 0.10-stable.

i created a debian package with the diff from debian's 0.10.2-1 and applied to the 0.10-stable branche and it worked fine.

[anonymous]

I was experiencing this problem with trac-0.10.2-1.fc6 on Fedora Core 6, but the problem disappeared when I upgraded to trac-0.10.3-1.fc6.

Thanks for the great work - trac is great.

-M

[anonymous]

the correct svn checkout command is:

svn co http://svn.edgewall.org/repos/trac/branches/0.10-stable

I also needed to restart apache (apachectl restart) before the error went away.

[cboos]

Thanks, fixed the URL. See also TracDownload#Tracstable.