Re: recent client-side corruptions and Alpha

Karl Fogel <kfogel@newton.ch.collab.net> writes:

> We might establish that the problem is due to a particular
> revision(s), which could be reverted for release, and then worked on
> at our leisure. But I tend to think that if we pinpoint the
> revisions, we have pinpointed the cause, and should just work on the
> fix from there -- I mean, how long can it take?

It fairly obviously crashed in my new baton code, it got a NULL from
apr_hash_get and used that as a valid svn_wc_adm_access_t. Now that
appears to mean that one of the commit_items paths passed to
svn_client__do_commit has not been locked by the earlier call to
svn_client__harvest_committables. I don't think that should be
possible.

I suppose the hash could have been corrupted, in which case the bug
could be almost anywhere. Another alternative is that the names used
to lock and to retrieve don't match, a trailing slash or something.
That's why I would like to know the exact command line parameters.

We could revert the new baton code, but if the problem is corruption
of the hash that may not solve the problem. Also by the time we get
to svn_wc_process_committed I think the commit has already been sent
to the server. I don't see how a crash updating the working copy can
cause server corruption :-(

-- 
Philip Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org