Edgewall Software
Modify

Opened 8 years ago

Closed 8 years ago

Last modified 8 years ago

#10422 closed defect (worksforme)

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

Reported by: anonymous Owned by: Christian Boos
Priority: normal Milestone:
Component: version control/changeset view Version: 0.12.2
Severity: normal Keywords: verify svn17
Cc: trac_10422@… Branch:
Release Notes:
API Changes:

Description

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.

Attachments (1)

test-t10422.dump (7.4 KB ) - added by Christian Boos 8 years ago.
sample repository for testing this issue

Download all attachments as: .zip

Change History (14)

comment:1 by trac_10422@…, 8 years ago

Cc: trac_10422@… added

comment:2 by Christian Boos, 8 years ago

Resolution: duplicate
Status: newclosed

Duplicate of #10414.

(got the wrong number at first).

Last edited 8 years ago by Christian Boos (previous) (diff)

comment:3 by Christian Boos, 8 years ago

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!

comment:4 by anonymous, 8 years ago

Resolution: duplicate
Status: closedreopened

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

comment:5 by Christian Boos, 8 years ago

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.

comment:6 by anonymous, 8 years ago

yes:

Trac0.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

comment:7 by anonymous, 8 years ago

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

comment:8 by Christian Boos, 8 years ago

Keywords: verify added
Milestone: 0.12.3
Owner: set to Christian Boos
Status: reopenednew

Ok, I'll try to reproduce this.

comment:9 by Remy Blank, 8 years ago

Keywords: svn17 added

comment:10 by Christian Boos, 8 years ago

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

by Christian Boos, 8 years ago

Attachment: test-t10422.dump added

sample repository for testing this issue

comment:11 by anonymous, 8 years ago

Resolution: fixed
Status: newclosed

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)!

comment:12 by Remy Blank, 8 years ago

Milestone: 0.12.3
Resolution: fixedworksforme

Thanks for the feedback.

comment:13 by Alexander Kriegisch <kriegaex@…>, 8 years ago

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.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.