I think the assert is due to something. I'm doing some work on property handling and the same assert is triggering consistently, so I should be able to track it. I'll add details to the new bug. On Jun 14, 2012 12:19 AM, "Philip Martin" <philip.mar...@wandisco.com> wrote:
> 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 >
