Changeset view broken for deleted files after upgrade to Subversion 1.7.0

[csapuntz@…]

Upgraded to Subversion 1.7.0 compiled by WanDisco on Centos 5.5.

New commits with file deletions no longer render in changeset view. Instead I get a "No node for /path in revision x" error.

Looking at the node_changes database, all the entries are marked E, even though the deletions should be marked D

Playing around on my test instance, I isolated the problem to a change in behavior between Subversion 1.6.x and 1.7.0. In Subversion 1.6.x, the change.path was None on a delete. In Subversion 1.7.0, the change.path is the path of the file that was deleted.

Recommend changing code

            if not path:
                 if base_path:

to

           if change.action == repos.CHANGE_ACTION_DELETE:
               if base_path:

in svn_fs.py. Not sure if that breaks compatiiblity with old subversion bindings though.

Problem observed on 0.11.7 but seems to exist in 0.13dev too.

[Remy Blank]

Thanks for the report and fix! This should go into 0.12.3.

[Remy Blank]

Fortunately, macports has updated their Subversion port to 1.7.0, so I could test the issue. There's indeed a change in svn.repos.ChangeCollector.delete_entry(), where the construction of ChangedPath now takes a non-None path argument. This seems like a pretty arbitrary change, and I'm a bit worried there may be other "vicious" issues like this popping up.

Anyway, your fix is almost correct, except for the fact that change.action was only introduced in 1.5.0, and AFAIK we still support 1.3 and 1.4. The complete fix is in [10833], and passes all tests with Subversion 1.6.17 and 1.7.0 (I don't have older versions, unfortunately).

[Christian Boos]

#10422 was closed as duplicate.

[info@…]

Nope.

copied new revision to folder, renamed old one to .orig, compiled, restarted apache

svn versioncontrol # diff svn_fs.py svn_fs.py.orig 907d906 < action = getattr(change, 'action', None) 914,917c913,914 < if not path and not new_path and self.scope == '/': < action = Changeset.EDIT # root property change < elif not path or action == repos.CHANGE_ACTION_DELETE: < if new_path: # deletion —-

if not path: # deletion

if new_path:

919a917,918

elif self.scope == '/': # root property change

action = Changeset.EDIT

But still I see:

No node trunk/xxx/yyy at revision 123

therefore reopening the ticket.

[Remy Blank]

Can you please provide some context info about your setup: Trac & Subversion version info, OS, how you installed (egg, from source, …)? Also, can you describe what the revision 123 does: number of adds, removes and changes?

[anonymous]

Replying to rblank:

Can you please provide some context info

Gentoo OS, on a KVM which looks like 64bit linux

svn versioncontrol # uname -a
Linux svn 2.6.37-gentoo #4 SMP Mon Feb 21 23:18:36 CET 2011 x86_64 Intel(R) Xeon(R) CPU L5410 @ 2.33GHz GenuineIntel GNU/Linux

trac is 0.12.2 subversion is 1.7.1 apache is 2.2.21 python is 2.7

I installed through the normal Gentoo portage system (emerge …), the whole show runs under mod_python - I think. There are some trac-hacks installed, mainly via easy_install <subversion path>

The changeset definitely deletes trunk/xxx/yyy at given revision, maybe there are some more edits. The reason why I found this ticket entry was because since update to subverion 1.7. every changeset that includes a deletion, gives that error. Everything else works.

Trac also has no problems showing subsequent/previous changesets - as long as these don't contain a deletion.

[Christian Boos]

Replying to info@…:

Nope.

copied new revision to folder, renamed old one to .orig, compiled, restarted apache

did you resync? (see TracAdmin if needed)

[anonymous]

Replying to cboos:

did you resync? (see TracAdmin if needed)

No I haven't which may very well be the culprit. Unfortunately I hit something else when trying:

Trac [/data/trac/pmdoc]> help resync
AttributeError: 'WorklogAdminPanel' object has no attribute 'get_admin_commands'

Will fix that 1st and give feedback on behaviour after resync.

[anonymous]

Ok. After having hacked worklog/webadminui (by simply adding an empty method according to ​http://trac-hacks.org/ticket/7982)

After finding out that trac-admin docs are shitty (separate story).

And doing the resync and Apache restart

⇒ Works!

[ssomers@…]

I think there is something missing in the explanation, if not in the fix.

The original defect, and my experience with 0.12.2, is that only new commits with file deletions were corrupt. I gather that is because only the new commits are synced. Explicitly syncing old commits with deletions, between trac 0.12.2 and svn 1.7, should break the display of old commits. But I did my best to sync such old commits ("repository resync", "changeset modified") and they keep on coming out fine. Perhaps I'm not syncing the right way - all I can say is that changes in log messages are propagated.

Secondly, as in the description, the main changeset page, for instance http://host/repo/changeset?10068, displays the "No node for <path> at revision 10068" error, and the log barks:

Trac[main] WARNING: HTTPNotFound: 404 No such node (No node <path> at revision 10068)")

But another changeset page http://host/repo/changeset?new=10068&old=10067 (which is roughly where you go when comparing with the previous revision in Revision Log) looks perfectly fine. So trac 0.12.2 is able to understand svn 1.7 anyway?

Thirdly, as you might expect, just upgrading to branches/0.12-stable@10902 doesn't seem to get rid of the error, but that would be explained if I'm not syncing right.

[Christian Boos]

Replying to ssomers@…:

I think there is something missing in the explanation, if not in the fix.

Secondly, as in the description, the main changeset page, for instance http://host/repo/changeset?10068, displays the "No node for <path> at revision 10068" error, and the log barks:

Trac[main] WARNING: HTTPNotFound: 404 No such node (No node <path> at revision 10068)")

But another changeset page http://host/repo/changeset?new=10068&old=10067 (which is roughly where you go when comparing with the previous revision in Revision Log) looks perfectly fine. So trac 0.12.2 is able to understand svn 1.7 anyway?

Sorry, I have some trouble understanding what works and what doesn't with your setup.

Could you please:

• confirm that /changeset/10067 works and /changeset/10068 doesn't
• show us what svn log -v -r 10067 -r 10068 produces
• what's in your trac database (e.g. for sqlite3):

  sqlite3 yourtracenv/trac.db 'select * from node_change where repos = 33 and rev in ("0000010067", "0000010068")'
  

  (adapt repos = 33 to your setup or drop this clause if you have only one repository)
• if there's a traceback of some sort in the log when you're looking at changeset/10068, include it

Finally, I'd ask you to perform a trac-admin yourtracenv resync again, with 0.12.3dev (at least with [10833]) and be sure that you have 0.12.3dev getting used at that point (e.g. by running first trac-admin --version).

[cgbrown@…]

We're running Trac 0.11 over at ProjectLocker and ran into this issue when we upgraded to Subversion 1.7. Applying the backport described at ​http://blog.alternation.net/fixing-trac-011-for-subversion-17 based on changeset [10833], followed by a resync of any repository that was having a problem, seems to have repaired the issue for us.

[ssomers@…]

The core of my comment is basically a workaround, for those who upgraded the svn server to 1.7 and want to stick to a stable trac version. If you stumble upon the error page (because you're looking at a changeset that contains a deletion), go back and follow a link that has as tooltip "View Revision Log" instead of "View changeset". Then compare to the previous revision. Logically, looking at changeset 10902 is the same as comparing revision 10902 to 10901, In comments, if links like r10902 or changeset:10902 lead to a broken page, write diff:@10902:10901 for the time being.

I shouldn't have been confused that this works, because I was looking at the ChangeCollector code mentioned earlier and that can't deal with general difference reports. There must be other code dealing with general differences reports, and apparently/fortunately svn 1.7 didn't change the API used there.

Thanks for the feedback on how to investigate the syncs. I'll report what went wrong.

[ssomers@…]

comparing revision 10902 to 10901

Sorry, I should have written comparing from 10901 to 10902. And the link is diff:@10901:10902.

[ssomers@…]

I'm not 99% sure the story of syncing goes like this:

• Command "trac-admin yourtracenv resync" does not exist
• Command "trac-admin yourtracenv repository resync '' 1234" says "1234 resynced on (default)." but it doesn't update the changeset. It only updates the log message.
• Command "trac-admin yourtracenv repository resync ''" is the command you need to update the changeset.

This complete sync does take a considerable amount of time, comparable to an svn dump. If you only have a few items to repair, you could do it manually instead:

• First check you have a single repository (don't ask me why you would want more than one):

  sqlite3 yourtracenv/db/trac.db 'select count(distinct repos) from node_change'
  

• Check the state of the change:

  sqlite3 yourtracenv/db/trac.db 'select change_type from node_change where rev="0000001234" and path="trunk/the_file_deleted_then"'
  

This prints E (for edit?) and should print D (for delete).

• Fix the state of the change:

  sqlite3 yourtracenv/db/trac.db 'update node_change set change_type="D" where rev="0000001234" and path="trunk/the_file_deleted_then"'