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.martin_at_wandisco.com>
wrote:
> Justin Erenkrantz <justin_at_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
>
Received on 2012-06-14 08:02:55 CEST