Justin Erenkrantz <jus...@erenkrantz.com> writes: > (I do not have an easy way to login to the issue tracker from my iPad...so, > moving back to the list...) > > I really do not think the assert is due to memory corruption - nothing I > saw indicated that was happening. I think it is far more likely that there > is another bug somewhere. (It is the simplest explanation, IMHO.) > > If the checkout continues beyond the xxx lines in that patch (the xxx lines > indicate when we would have otherwise gone into a bad state and hung later > on) and does not end up in an infinite loop or hang, then I think this > issue can be resolved. And, someone who knows more about libsvn_wc can > investigate the assert. In the meantime, I will clean up the patch > tomorrow and commit it to serf... -- justin
>> svn: E235000: In file '../src/subversion/libsvn_wc/wc_db.c' line 1707: >> assertion >> failed (SVN_IS_VALID_REVNUM(changed_rev)) When this happens all of changed_rev changed_date and changed_author are invalid. It appears the update editor's close_file callback has been invoked before receiving the properties that set those fields. If I patch the client to set changed_rev to a valid revision then the client no longer asserts at this point and the close_file callback adds the file to wc.db. Then the client SEGVs or asserts in serf a short while later when attempting to process the properties that should have been processed before calling close_file. -- uberSVN: Apache Subversion Made Easy http://www.uberSVN.com