The content of this topic has been archived on 23 Apr 2018. There are no obvious gaps in this topic, but there may still be some posts missing at the end.
Anyone encountered SVN issue when updating?
svn up
Updating '.':
svn: E235000: In file 'subversion/libsvn_wc/update_editor.c' line 1583: assertion failed (action == svn_wc_conflict_action_edit || action == svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace)
Aborted (core dumped)I did ran into the same assertion error with changeset 33655 in my windows repository, but not in the Linux build system.
In file
'D:\Development\SVN\Releases\TortoiseSVN-1.7.9\ext\subversion\subversionlibsvn_wc\update_editor.c'
line 1583: assertion failed (action == svn_wc_conflict_action_edit || action
== svn_wc_conflict_action_delete || action == svn_wc_conflict_action_replace)
I reported the error also to TortoiseSVN bug tracker, but got feedback that the error is related to the main subversion libraries, not just the TortoiseSVN GUI. (http://tortoisesvn.tigris.org/ds/viewMe … Id=3018909)
That changeset r33655 contains in addition to normal changes for bcm_tag.h also a removal of a "special property": https://dev.openwrt.org/changeset/33655
After several cleanup/resolve/delete etc. attempts I got my repository straightened up.
(Last edited by hnyman on 9 Oct 2012, 15:30)
How do you resolve it?
The problem is that the SVN on my Fedora 17 doesn't tell me which commit caused it, just core dumped itself.
Check that changeset and the files touched by it. You might try deleting those files and letting svn to recreate the newest version. I succeeded after several different attempts, but I am not quite sure what was the defining fix.
Solved it. Thanks for the guidance
svn cleanup
svn rm tools/firmware-utils/src/bcm_tag.h
svn up
The problem is that the SVN on my Fedora 17 doesn't tell me which commit caused it, just core dumped itself.
Neither did my svn provide any concrete feedback. I found the problematic changeset by trying "svn up" a directory at a time, and then drilling deeper to subdirectories when a directory caused the error.
Great to hear that you solved it.
Apparently this is something that pops up with certain svn versions/environments, so some Openwrt users will run to it, while others escape without ever encountering the error related to that problematic changeset.
The discussion might have continued from here.