HTTPNotFound: 404 No such node (No node path/in/repo at revision XY)

[anonymous]

I have two changeset in my svn-repo that make trac problems to dispaly the content of the changeset. It may have to do with the fact that the admin upgraded svn to 1.7 and postgres 9.1.

The svn-upgrade happened last week, the postgres upgrade happened today (before the two suspicious changes where commited).

In my browser I get

Error: No such node

No node path/2/deleted/file.ext at revision 4263

in the tracd-logfile I get

2011-10-18 14:40:31,926 Trac[main] WARNING: HTTPNotFound: 404 No such node (No node path/2/deleted/file.ext at revision 4263)

the change itself looks like (when I'm inside the WC):

svn log -v -c 4263

------------------------------------------------------------------------
r4263 | username | 2011-10-18 14:21:36 +0200 (Tue, 18 Oct 2011) | 3 lines
Changed paths:
   D /path/2/deleted/file.ext
   D /path/2/deleted/2nd_file.ext
   D /path/2/deleted/3rd_file.ext
   D /path/2/deleted/4th_file.ext
   D /path/2/deleted/5th_file.ext
   D /path/2/deleted/6th_file.ext
   D /path/2/deleted/7th_file.ext
   D /path/2/deleted/8th_file.ext
   D /path/2/deleted/9th_file.ext
   D /path/2/deleted/10th_file.ext

 * ticket:2335
 * test views removed

------------------------------------------------------------------------

The system is solaris on AMD64, pgsql 9.1, trac 0.12.2, svn 1.7.0 (r1176462).

I do have another changeset that has the same problem to display the changeset-view. It does not only contain deletes but also modifications and new files but the error-message displays argues about the first removed file.

But there are (historic) changesets (comitted after the svn-upgrade) that contain removed files that are displayed correctly in trac.

Please let me know if I should provide more detailed information.

[Christian Boos]

Duplicate of #10414.

(got the wrong number at first).

[Christian Boos]

It would be great if you could upgrade to latest 0.12-stable, and verify that the problem is fixed for you, and report back. Thanks!

[anonymous]

I've upgraded to

URL: http://svn.edgewall.org/repos/trac/branches/0.12-stable
Repository Root: http://svn.edgewall.org/repos/trac
Repository UUID: af82e41b-90c4-0310-8c96-b1721e28e2e2
Revision: 10843

but that made no difference. The same error remains

[Christian Boos]

Are you sure you're running that version?

Check the version info in the /about page, as TRAC_ADMIN, or look into the trac.log.

[anonymous]

yes:

Trac	0.12.3dev
Genshi	0.6
psycopg2	2.4.2
Pygments	1.4
Python	2.7.2 (default, Jul 19 2011, 09:13:48) [GCC 4.4.6]
pytz	2010o
setuptools	0.6c11
Subversion	1.7.0 (r1176462)
jQuery:	1.4.4

[anonymous]

if I can provide more info, just let me know…

[Christian Boos]

Ok, I'll try to reproduce this.

[Christian Boos]

Well, I installed the bindings for 1.7.0, created a sample repository (test-t10422.dump​) and resynced it without a problem. All changesets show up fine.

But it all depends how you use Trac of course: if you try to view a file which has been deleted at the precise revision where it has been deleted, then the "No such node" error message is expected. We take care of not presenting such links to the user. For example with the test repository above the changeset 7 will list the deleted files but the link will go to the version 6 of the file e.g. /browser/test-t10422/path/2/deleted/9th_file.ext?rev=6 (the link hint says "Show what was removed (content at revision 6)"). If you change that 6 to a 7 in the URL, you will indeed get the "No such node" error.

So I suggest that you create a repository from the dump (svnadmin create test-t10422-repos; svnadmin load test-t10422-repos < test-t10422.dump) and that you add this repository to Trac (trac-admin $tracenv repository add test-t10422 test-t10422-repos svn) and resync it (trac-admin $tracenv repository resync test-t10422). If the resync succeeds, you should then be able to dump the content of the database:

$ sqlite3 $tracenv/db/trac.db "select * from node_change where repos=(select id from repository where value='test-t10422')"
28|0000000001|path|D|A||-1
28|0000000002|path/2|D|A||-1
28|0000000002|path/2/deleted|D|A||-1
28|0000000003|path/2/deleted/10th_file.ext|F|A||-1
28|0000000003|path/2/deleted/2th_file.ext|F|A||-1
28|0000000003|path/2/deleted/3th_file.ext|F|A||-1
28|0000000003|path/2/deleted/4th_file.ext|F|A||-1
28|0000000003|path/2/deleted/5th_file.ext|F|A||-1
28|0000000003|path/2/deleted/6th_file.ext|F|A||-1
28|0000000003|path/2/deleted/7th_file.ext|F|A||-1
28|0000000003|path/2/deleted/8th_file.ext|F|A||-1
28|0000000003|path/2/deleted/9th_file.ext|F|A||-1
28|0000000004|path|D|D|path|3
28|0000000005|path|D|A||-1
28|0000000005|path/2|D|A||-1
28|0000000005|path/2/deleted|D|A||-1
28|0000000006|path/2/deleted/10th_file.ext|F|A||-1
28|0000000006|path/2/deleted/2th_file.ext|F|A||-1
28|0000000006|path/2/deleted/3th_file.ext|F|A||-1
28|0000000006|path/2/deleted/4th_file.ext|F|A||-1
28|0000000006|path/2/deleted/5th_file.ext|F|A||-1
28|0000000006|path/2/deleted/6th_file.ext|F|A||-1
28|0000000006|path/2/deleted/7th_file.ext|F|A||-1
28|0000000006|path/2/deleted/8th_file.ext|F|A||-1
28|0000000006|path/2/deleted/9th_file.ext|F|A||-1
28|0000000007|path/2/deleted/10th_file.ext|F|D|path/2/deleted/10th_file.ext|6
28|0000000007|path/2/deleted/2th_file.ext|F|D|path/2/deleted/2th_file.ext|6
28|0000000007|path/2/deleted/3th_file.ext|F|D|path/2/deleted/3th_file.ext|6
28|0000000007|path/2/deleted/4th_file.ext|F|D|path/2/deleted/4th_file.ext|6
28|0000000007|path/2/deleted/5th_file.ext|F|D|path/2/deleted/5th_file.ext|6
28|0000000007|path/2/deleted/6th_file.ext|F|D|path/2/deleted/6th_file.ext|6
28|0000000007|path/2/deleted/7th_file.ext|F|D|path/2/deleted/7th_file.ext|6
28|0000000007|path/2/deleted/8th_file.ext|F|D|path/2/deleted/8th_file.ext|6
28|0000000007|path/2/deleted/9th_file.ext|F|D|path/2/deleted/9th_file.ext|6

[Christian Boos]

sample repository for testing this issue

[anonymous]

I've created the test-repo and imported your dump, added this as second repo in my trac-project and I could browse all changesets and they have been showed correctly.

Since trac requested a full-repo-resync for the newly added repo, I also ran this whole resync for my other repo and the failure was gone.

Before I filed this ticked I already ran resyncs for the suspicious revisions (and with the old trac 0.12.2) with no avail.

Thank you very much for your support (and this incredible piece of software)!

[Remy Blank]

Thanks for the feedback.

[Alexander Kriegisch <kriegaex@…>]

We also had that problem aber SVN server upgrade from 1.6.3 to 1.7.1 and I can acknowledge that a repo resync was not helpful before upgrading via easy_install http://svn.edgewall.org/repos/trac/branches/0.12-stable.

After the upgrade a manual resync for a damages revision still was not helpful, very strange indeed. But a full repo resync after the upgrade solved the problem, as mentioned above. I just wanted to point out this important part of the solution.