[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: recent client-side corruptions and Alpha

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2002-07-13 00:27:08 CEST

Blair Zajac <blair@orcaware.com> writes:

> Karl Fogel wrote:
> >
> > Well, naturally, our first incident of client-side corruption in a
> > long time happens two days before Alpha :-).
> >
> > If we can track down and fix the source of Kevin's problem before
> > Monday, then great. If not, though, we can't release Alpha with a
> > known bug like this, so we should devote all resources to tracking it
> > down.
> I don't know if this helps, but when I got my core dump when the
> post-commit script failed, it looked like the revision was committed
> to the repository because svn log would show the new commit message,
> but the local working files would still show differences with svn
> diff just as if the files were not committed. So I'm guessing that
> the local files in the .svn directory were not updated to match the
> repository???

I have a hypothesis about what happened to pilchie. I think it's
happened to me and cmpilato a long time ago.

1. Suppose your working copy has file 'foo' at revision 1, and you
    modify your working file to have local mods. The working file is
    now effectively r1+M.

2. You commit, creating revision 2 on the server. But somehow, in wc
    post-commit processing you crash. You crash in such a way that
    foo's entry has it's working-revision bumped to '2', but somehow
    the old rev 1 textbase is still installed (!)

3. Now your wc thinks it has r2 of foo, and still shows local mods.
    The diffs are still the same: they look like the diffs between r1
    and r1+M.

4. Frustrated by the previous crash, you attempt to commit your mods
    again. Your working copy reports that you're committing against
    r2 of foo, so there's no server-side conflict; and now you send
    *binary* diffs between r1 and r1+M and unknowingly apply them to
    r2 of foo on the server (which already looks like r1+M). Voila,
    instant garbage.

    [This looks a lot like the garbage pilchie committed... notice
    that it looks like some odd changes applied to the exact same
    place twice in a row, like a binary diff recursing on its output.]

The question is: how does the situation is step #2 arise?

Perhaps the commit succeeds, and then post-commit hook fails on the
server... the post-commit hook error is transmitted back to the
client, and this causes the bizarre crash scenario whereby *only* the
working rev is bumped.

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 13 00:31:49 2002

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.