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