Using a 'subrepository' in Trac generates errors

[Manuzhai]

I'm trying to use the subrepository feature in Trac, that allows for limiting the changesets and the browser to a certain directory in the SVN repos. In my case, the repos is at /var/svn/xm and I'm trying to watch the /joss dir in the repos. When viewing the timeline, I now get the following traceback:

Traceback (most recent call last):
  File "/usr/lib/python2.4/site-packages/trac/web/modpython_frontend.py", line 205, in handler
    dispatch_request(mpr.path_info, mpr, env)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 139, in dispatch_request
    dispatcher.dispatch(req)
  File "/usr/lib/python2.4/site-packages/trac/web/main.py", line 107, in dispatch
    resp = chosen_handler.process_request(req)
  File "/usr/lib/python2.4/site-packages/trac/Timeline.py", line 137, in process_request
    filters)
  File "/var/www/trac/trac/versioncontrol/web_ui/changeset.py", line 109, in get_timeline_events
    chgset = repos.get_changeset(rev)
  File "/var/www/trac/trac/versioncontrol/cache.py", line 42, in get_changeset
    self.sync()
  File "/var/www/trac/trac/versioncontrol/cache.py", line 60, in sync
    current_rev = self.repos.next_rev(youngest_stored)
  File "/var/www/trac/trac/versioncontrol/svn_fs.py", line 272, in next_rev
    idx = self.history.index(rev)
ValueError: list.index(x): x not in list

This is with r2235. (I think there should be a component for the versioncontrol stuff, btw.)

[Manuzhai]

This actually also happens when trying to Browse Source. That kinda makes sense, since the error is in the fairly low-layer svn_fs.py, so it influences a lot of code on top of that.

[Christian Boos]

Maybe it has nothing to do with your error, but while trying to reproduce this one by restricting my repos to a subpath, I had to make one fix to avoid another error.

Though I couldn't reproduce the problem reported here, you may want to check again with r2236…

Also, please give more informations: I assume your repository_path is /var/svn/xm/joss, but what are the files listed in the changeset introducing the problem, i.e. the one corresponding to the rev in the repos.get_changeset(rev) from the stack trace above?

[Manuzhai]

Hmm, I upped to r2237, but that doesn't fix the error.

What's the supposed rev order in self.history? Logging using the following diff in get_next_rev():

Index: trac/versioncontrol/svn_fs.py
===================================================================
--- trac/versioncontrol/svn_fs.py       (revision 2237)
+++ trac/versioncontrol/svn_fs.py       (working copy)
@@ -269,6 +269,8 @@
             return rev + 1
         if rev == 0:
             return self.oldest_rev
+        for i in range(5):
+            self.log.debug(str(self.history[-i]))
         idx = self.history.index(rev)
         if idx > 0:
             return self.history[idx - 1]

gives me this, which seems a little weird:

19:01:26 Trac[svn_fs] DEBUG: 508
19:01:26 Trac[svn_fs] DEBUG: 285
19:01:26 Trac[svn_fs] DEBUG: 367
19:01:26 Trac[svn_fs] DEBUG: 368
19:01:26 Trac[svn_fs] DEBUG: 369

In my problem, 505 is already in the database. 506 contains unrelated changes (not in /joss/), 507 has some changes on a branch, and 508 has similar changes on trunk:

manuzhai@supaari /var/www/trac $ svn log -r506 -v http://svn.xavamedia.nl/joss/
------------------------------------------------------------------------
manuzhai@supaari /var/www/trac $ svn log -r507 -v http://svn.xavamedia.nl/joss/
------------------------------------------------------------------------
r507 | Manuzhai | 2005-09-11 13:32:39 +0000 (Sun, 11 Sep 2005) | 1 line
Changed paths:
   M /joss/branches/staroil/assets/css/skin.css
   M /joss/branches/staroil/assets/menu.xml
   M /joss/branches/staroil/assets/style.xsl
   M /joss/branches/staroil/joss/control/contact.py
   M /joss/branches/staroil/php/head.php

[Joss] Fixes #38, #39 and references #15.
------------------------------------------------------------------------
manuzhai@supaari /var/www/trac $ svn log -r508 -v http://svn.xavamedia.nl/joss/
------------------------------------------------------------------------
r508 | Manuzhai | 2005-09-11 13:47:52 +0000 (Sun, 11 Sep 2005) | 1 line
Changed paths:
   M /joss/trunk/assets/css/positioning.css
   M /joss/trunk/joss/control/contact.py
   M /joss/trunk/php/head.php

[Joss] Change enquiry form email, refine graphic header generation.
------------------------------------------------------------------------

Your assumption of my repository_dir (not _path) is correct.

[Manuzhai]

Okay, I think I figured it out! When you change your Trac environment to have a subrepository as its repository, it has all these revisions in there that don't necessarily pertain to the selected subrepository. This throws off the get_next_rev() calculation, because some last rev that is in the cache may not actually be a rev of the selected scope-node, and so it tries to find the next rev from that rev, but since it can't really find that rev it also can't find the next rev from it!

So I guess there should be some kind of restriction on the changing of the repository_dir, so that Trac gives off a warning about this?

[Christopher Lenz]

Doesn't a trac-admin resync solve this?

[Christian Boos]

What we could maybe do is to record the repository_dir in the system table, and while checking for resync, force a full resync if the repository_dir value has changed?

[Christian Boos]

Hm, the above was not that clear, I meant:

The user should still configure the repository_dir in the trac.ini, but when Trac is doing a resync operation, it should also save the repository_dir which was used for this resync in the system table. That way, if the configuration file has been updated, we would be able to know if the complete revision and node_change table are still relevant or should be resynced.

(I hope it's clearer now)

[Christian Boos]

Automatically resync the cache for the whole repository if the 'repository_dir' has changed (Note: the unit-tests for cache.py were not updated; would need to "mock" the environment)

[Christian Boos]

The previous idea has been implemented in the attachment:2044-auto-resync.patch​ made against the 0.9b1 release.

[Christian Boos]

I'll put this on hold, while considering a more general solution that would take #2086 into account.

[Christian Boos]

… in the meantime, I wrote another patch​ which solves this problem in a satisfying way.

Therefore I'm closing this ticket as a duplicate of #2107.