Philip Martin <philip@codematters.co.uk> writes:
> Karl Fogel <kfogel@newton.ch.collab.net> writes:
>
> > Philip Martin <philip@codematters.co.uk> writes:
> > > I have a patch that implements this. It's quite straightforward and I
> > > believe it works as well as the current implementation. Given our
> > > current corruption bug, should I commit it?
> >
> > I hate to ask you to wait... But, I think it would be best to wait.
> > Until we know more, we should avoid further code churn in libsvn_wc,
> > except for outright bug fixes.
> >
> > How about this: post the patch here first. At least that way it can
> > be reviewed while we're working on the bug.
>
> I believe the problem has been identified. Kevin interrupted a
> previous commit, which would leave some directories locked.
> harvest_committables calls lock_dir to lock directories but doesn't
> check that it succeeds. So there should have been an "already locked"
> error before starting the commit, but that did not occur, the commit
> went ahead and then the NULL lock structure from the failed lock
> attempt caused a core dump.
This sounds like a more specific validation of my hypothesis; we've
actually described exactly how, in our code, my hypothesis can
happen. And all of pilchie's symptoms seem to match.
In essence, the bug is that our commit code wasn't "playing ball" with
other code in terms of honoring locks, and thus an unfinished log was
never run. Bang, inconsistent wc state.
I say: we should review and apply the fix!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Jul 14 21:32:13 2002