Re: nasty commit bug

Karl Fogel <kfogel@newton.ch.collab.net> writes:
> > OK, it looks like the hash lookup has returned NULL, that should not
> > happen. However the commit has already been sent to the server so I
> > don't think this can be responsible for the corruption.
>
> Yeah. We *seriously* need a repro case for this right now...

Pilchie, maybe we can make a repro case using your working copy, which
has already been known to have a problem at least once.

First, run

   $ svn st -v

on that working copy. I know you've already made the commit, but you
haven't committed anything *since* then, I assume, and we know what
local mods you intended to make, so if we have

   1. Your "svn st -v" output
   2. A patch giving the local mod you meant to commit

... then we can probably reconstruct your working copy at the time you
committed, and thus reconstruct your working copy as it was before the
commit.

The hard part is that we don't know if your text bases were corrupted
before the commit or not. But, if those two text bases were
corrupted, chances are others were too. So, *after* doing the above,
could you do this:

   $ find . -name "*.[ch]" | xargs touch
   $ svn st -v
   $ svn diff

That will invalidate all your timestamps, forcing a text-base
comparison for the working files. If anything looks different here,
we may have a lead.

Thanks,
-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Jul 12 20:36:25 2002