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

Reply via email to